| Title | On fast and accurate detection of unauthorized wireless access points using clock skews |
| Publication Type | thesis |
| School or College | College of Engineering |
| Department | Computing |
| Author | Jana, Suman |
| Date | 2009-05-06 |
| Description | We explore the use of clock skew of a wireless local area network access point (AP) as its fingerprint to detect unauthorized APs quickly and accurately. The main goal behind using clock skews is to overcome one of the major limitations of existing solutions - the inability to effectively detect Medium Access Control (MAC) address spoofing. We calculate the clock skew of an AP from the IEEE 802.11 Time Synchronization Function (TSF) timestamps sent out in the beacon/probe response frames. We use two different methods for this purpose - one based on linear programming and the other based on least square fit. We supplement these methods with a heuristic for differentiating original packets from those sent by the fake APs. We collect TSF timestamp data from several APs in three different residential settings. Using our measurement data as well as data obtained from a large conference setting, we find that clock skews remain consistent over time for the same AP but vary significantly across APs. Furthermore, we improve the resolution of received timestamp of the frames and show that with this enhancement our methodology can find clock skews very quickly, using 50-100 packets in most of the cases. We also discuss and quantify the impact of various external factors including temperature variation, virtualization, clock source selection and NTP synchronization on clock skews. Our results indicate that the use of clock skews appears to be an efficient and robust method for detecting fake APs in wireless local area networks. |
| Type | Text |
| Publisher | University of Utah |
| Subject | Wireless LANs; Medium Access Control |
| Dissertation Institution | University of Utah |
| Dissertation Name | MS |
| Language | eng |
| Relation is Version of | Digital reproduction of "On fast and accurate detection of unauthorized wireless access points using clock skews" J. Willard Marriott Library Special Collections TK7.5 2009 .J36 |
| Rights Management | © Suman Jana |
| Format | application/pdf |
| Format Medium | application/pdf |
| Format Extent | 357,122 bytes |
| Identifier | us-etd2,121623 |
| Source | Original: University of Utah J. Willard Marriott Library Special Collections |
| Conversion Specifications | Original scanned on Epson GT-30000 as 400 dpi to pdf using ABBYY FineReader 9.0 Professional Edition. |
| ARK | ark:/87278/s6zk5x8q |
| DOI | https://doi.org/doi:10.26053/0H-8GYR-M0G0 |
| Setname | ir_etd |
| ID | 193546 |
| OCR Text | Show by in ON FAST AND ACCURATE DETECTION OF UNAUTHORIZED WIRELESS ACCESS POINTS USING CLOCK SKEWS by Suman Jana A thesis submitted to the faculty of The University of Utah in partial fulfillment of the requirements for the degree of Master of Science III Computer Science School of Computing The University of Utah August 2009 (c) Jana All Copyright © Suman J ana 2009 All Rights Reserved THE UNIVERSITY OF UTAH GRADUATE SCHOOL of a thesis submitted by Suman Jana This thesis has been read by each member of the following supervisory committee and by majority vote has been found to be satisfactory. S\ H ( f< = S r " - Chair: Sneha Kasera Rajeev Balasubromonian Neal Patwari SUPERVISORY COMMITTEE APPROVAL satisfactory. K. APPROVAL To the Graduate Council of the University of Utah: found that (1) its format, citations, and bibliographic style are consistent and acceptable; to The Graduate School. Date Chair, Supervisory Committee Martin Berzins Chair/Dean • Dean of The Graduate School THE UNIVERSITY OF UTAH GRADUATE SCHOOL FINAL READING APPROVAL I have read the thesis of Suman Jana in its final form and have (2) its illustrative materials including figures, tables, and charts are in place; and (3) the final manuscript is satisfactory to the Supervisory Committee and is ready for submission Sneha K. Kasera Approved for the Major Department Martin Berzins Chair/Dean Approved for the Graduate Council "'" .j<,C?~ -J..)e...-.I\ ). ~ - -. David S. Chapman fingerprint existing solutions - the inability to effectively detect Medium Access Control (MAC) address spoofing. We calculate the clock skew of an AP from the IEEE 802.11 Time Synchronization Function (TSF) timestamps sent out in the beacon/probe response frames. We use two different methods for this purpose - one based on linear programming and the other based on least square fit. We supplement these methods with a heuristic for differentiating original packets from those sent by the fake APs. We collect TSF timestamp data from several APs in three different residential settings. Using our measurement data as well as data obtained from a large conference setting, we find that clock skews remain consistent over time for the same AP but vary significantly across APs. Furthermore, we improve the resolution of received timestamp of the frames and show that with this enhancement our methodology can find clock skews very quickly, using 50-100 packets in most of the cases. We also discuss and quantify the impact of various external factors including temperature variation, virtualization, clock source selection and NTP synchronization on clock skews. Our results indicate that the use of clock skews appears to be an efficient and robust method for detecting fake APs in wireless local area networks. ABSTRACT We explore the use of clock skew of a wireless local area network access point (AP) as its fingerprint to detect unauthorized APs quickly and accurately. The main goal behind using clock skews is to overcome one of the major limitations of different resolution of received timestamp of the frames and show that with this enhancement our methodology can find clock skews very quickly, using 50-100 packets in most of the cases. We also discuss and quantify the impact of various external factors including temperature variation, virtualization, clock source selection and NTP synchronization on clock skews. Our results indicate that the use of clock skews appears to be an efficient and robust method for detecting fake APs in wireless local area networks. A B S T R A C T iv FIGURES vi C H A P T E R S 1. INTRODUCTION 1 2. RELATED W O R K 6 3. THREAT MODEL 8 4. METHODOLOGY 10 5. IMPLEMENTATION 18 6. EXPERIMENTAL RESULTS 21 6.1 Results from the Sigcomm Trace 22 6.2 Results from the Residential Traces 24 6.3 Differentiating Frames of Fake APs 27 6.4 Impact of External Factors on Clock Skews 30 6.4.1 Effect of Virtual APs 30 6.4.2 Effect of Temperature 31 6.4.3 Effect of NTP Synchronization of Fingerprinter's Clock 32 6.4.4 Effect of Fingerprinter's Clock Source Selection 32 7. FABRICATION OF CLOCK SKEWS 35 8. CONCLUSIONS A N D F U T U R E W O R K 40 REFERENCES 42 CONTENTS ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. IV LIST OF FIGURES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vii CHAPTERS 1. INTRODUCTION 1 2. RELATED WORK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. THREAT MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. METHODOLOGy.... . . .. .. .... .. . . ....... ......... . . . . . 10 4.1 Linear Programming Method (LPM) . . . . . . . . . . . . . . . . . . . . . . . .. 12 4.2 Least Square Fitting (LSF) . . ...... .. ..... .... ... . .. ..... . 13 4.3 Differentiating Frames of Fake APs . . . . . . . . . . . . . . . . . . . . . . . . .. 13 5. IMPLEMENTATION ..... . ... ... .... .. .................. 18 6. EXPERIMENTAL RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1 Results from the Sigcomm Trace . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22 6.2 Results from the Residential Traces. . . . . . . . . . . . . . . . . . . . . . . . .. 24 6.3 Differentiating Frames of Fake APs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4 Impact of External Factors on Clock Skews. . . . . . . . . . . . . . . . . . .. 30 6.4.1 Effect of Virtual APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30 6.4.2 Effect of Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.4.3 Effect of NTP Synchronization of Fingerprinter's Clock. . . . . . 32 6.4.4 Effect of Fingerprinter's Clock Source Selection ............ 32 7. FABRICATION OF CLOCK SKEWS. . . . . . . . . . . . . . . . . . . . . . 35 8. CONCLUSIONS AND FUTURE WORK. . . . . . . . . . . . . . . . . .. 40 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42 frame nat chihuahua estimations examined threshold LPM) LIST OF FIGURES 1.1 A fake AP attack scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2 4.1 Structure of fixed fields in beacon/probe response frame. . . . . . . . . .. 10 6.1 Skew estimates of samples containing 300 beacon packets sent by sigcomm-nat by taken at different times by chihuahua. . . . . . . . . . . .. 23 6.2 TSF clock offset-sets for two different linksys APs (clock skew esti-mations are -64.23 ppm and -45.69 ppm) . . ........... ... ....... 26 6.3 Mean correct packet separation rate versus number of packets exam-ined to estimate threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29 7.1 TSF clock offset-sets for the original AP (clock skew estimation is -178.83 ppm using LPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2 TSF clock offset-sets for the attacker with forged timestamps (clock skew estimation is -35 ppm using LPM). . . . . . . . . . . . . . . . . . . . . . . . 38 chihuahua) . . . packets) 1,200 packets) packets). measured measured set LIST OF TABLES 6.1 Skew estimates for samples containing beacon frames sent by sigcomm-nat (collected by with different sample sizes. 23 6.2 Skew estimates from Chihuahua (sigcomm-nat has 20,000 packets and sigcomm-public-2 has 7,500 packets). . . . . . . . . . . . . . . . . . . . . . . . . .. 24 6.3 Skew estimates from Kalahari (sigcomm-nat-foyer has 30,000 packets, sigcomm-public-2 has 20,000 packets and sigcomm-public-1 has 1,200 packets). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.4 Skew estimates from Sonoran (both APs have around 10,000 packets). 24 6.5 Skew estimates from Mojave (both APs have around 10,000 packets) . 25 6.6 Clock skew estimates in residential setting A as measured from laptop2 25 6.7 Clock skew estimates (Using LPM) in residential setting B as mea-sured from laptopl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.8 Clock skew estimates (Using LPM) in residential setting C as mea-sured from laptop2 ....... . .. . ... . ........................ 27 6.9 Measure of skew from the synthetic data set. . . . . . . . . . . . . . . . . . . .. 28 6.10 Skew of virtual APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.11 Comparison of clock skew estimates of same APs measured from laptop2 running on AC power and battery power in residential setting A .. .. . . ... . .. ... . ......... ... . .... . . . . ... . .......... ... 34 because of their importance in providing ubiquitous services and their inherent vulnerability due to broadcast nature of the wireless medium, the wireless local area networks (WLANs) are also becoming targets of a variety of attacks. One of the ways in which a WLAN can be attacked is by introducing one or more unauthorized fake Access Points (APs) in the network [3, 4, 11, 17]. A fake AP can be set up by a malicious attacker (Figure 1.1) to masquerade as an authorized AP by spoofing the authorized AP's medium access control (MAC) address. This fake AP is used to fool a wireless node in the WLAN into accessing the network through the fake AP instead of the authorized one. The fake AP can then launch a variety of attacks, thereby compromising the security of the wireless communication. Setting up fake APs is not hard. Public domain programs including rglueap [8] sniff 802.11 probe request frames to find out the default AP of the probing wireless node and then impersonate the default AP. Therefore, detecting unauthorized APs is a very important task of WLAN intrusion detection systems (WIDS). 802.Hi likely, the following practical issues can still make wireless networks using 802.Hi CHAPTER 1 INTRODUCTION With advances in micro-technology and wireless networks, networked mobile systems are becoming increasingly prevalent. There is also an ever growing demand for ubiquitous services. These two factors are fueling a wide scale deployment of wireless networks including the IEEE 802.11 wireless local area networks. However, inherent \VLAN of Setting rglueap probe request frames to find out the default AP of the probing wireless node and then impersonate the default AP. Therefore, detecting unauthorized APs is a very important task of WLAN intrusion detection systems (WIDS). The new wireless security enhancement 802.11i RSNA (Robust Security Network Association) uses traditional cryptographic methods (i.e., digital certificates) to provide strong mutual authentication between wireless clients and the APs. Although this solution, if implemented properly, will make the fake AP attack less 802.11i Fake AP Original AP Userl original one but does not support any security measures such as RSNA.1 Third, an attacker can also set up fake APs having the same identifiers (MAC address, basic service set identifier (BSSID) and service set identifier (SSID)) as the original AP and evade detection by using different physical channel characteristics (by using short/long preambles, operating in a different channel etc.). These facts motivate us to find a viable non cryptographic solution to the fake AP attack. We emphasize that this solution is not meant to replace existing cryptographic methods. Rather, it should be used in conjunction with the cryptographic methods to achieve a higher level of security in WLANs. The current state-of-the art noncrypto methods for unauthorized AP detection [3, 9, 11, 16, 17] cannot detect fake APs. fingerprinting ^ h i s 802. H i 2 ~ ... ---~U Internet WIDS Node User2 User3 User4 Figure 1.1. A fake AP attack scenario RSNA vulnerable. First, management and verification of digital certificates across different domains is known to be cumbersome. Second, as the current AP selection algorithms use signal strength as the only criteria for AP selection, users can be fooled to connect to the fake AP that has a higher signal strength compared to the l long etc.) . the 11 , In this thesis, we explore a passive online scheme that can detect fake APs with high accuracy and minimum overhead. This scheme, like the one proposed by Kohno et al. for fingerprinting personal computers and servers [28], is based IThis security rollback/downgrade attack is possible in 802.11i RSNA networks [26]. 3 drifts. vary significantly across devices thereby arguing that the clock skew of a device can be used as its reliable fingerprint. However, Kohno et al.'s scheme focused on wide area wired networks. Its application in a local area setting can result in higher accuracy. Unlike Kohno et al.'s scheme that uses TCP/ICMP timestamps, in our scheme, we use the Time Synchronization Function (TSF) timestamps in the IEEE 802.11 beacon/probe response messages sent by the AP, to determine its clock skew. The use of beacons has several advantages. First, beacons are sent all the time and at a fast rate (typically 10 to 100 frames per second) independent of any application. Second, the granularity of 802.11 TSF timer is one microsecond which is much higher than that of TCP timestamp clocks. Third, as the beacon timestamp is the actual time when an AP sends a frame (i.e., the time after the channel is sensed to be free) rather than the time when it is scheduled to send the frame, we do not need to consider any significant unpredictable delays incurred by the network as in the case of TCP timestamps. Therefore our scheme estimates more accurate clock skews and much faster compared to the TCP/ICMP timestamp approach [28]. We also improve upon the time taken for estimating the clock skew by using high precision timers, at the fingerprinting node, that have resolutions in the order of microseconds to measure the arrival time of beacon frames. that upperbounds all the time offsets calculated from the timestamps in the AP fingerprinting of this line is our clock skew estimate. Our second method is based on finding a line that is at the least square distance from all the time offsets. The slope of the line represents our estimate of clock skew. As we show later in Chapter 6, both of these methods perform their tasks fairly well. However, in the special case when the on estimating clock skews of APs. Clock skew is the rate at which a clock drifts. An AP's clock skew acts as its fingerprint. Kohno et al. [28, 31] has shown that the clock skew of a device remains fairly consistent over time but the clock skews TCP /timestamps, the IEEE 802.11 beacon/probe response messages sent by the AP, to determine its the time and at a fast rate (typically 10 to 100 frames per second) independent of any application. Second, the granularity of 802.11 TSF timer is one microsecond which is much higher than that of TCP timestamp clocks. Third, as the beacon timestamp is the actual time when an AP sends a frame (i.e., the time after the channel is sensed to be free) rather than the time when it is scheduled to send the frame, we do not need to consider any significant unpredictable delays incurred by the network as in the case of TCP timestamps. Therefore our scheme estimates more accurate clock skews and much faster compared to the TCP /ICMP timestamp approach [28]. We also improve upon the time taken for estimating the clock skew by using high precision timers, at the fingerprinting node, that have resolutions in the order of microseconds to measure the arrival time of beacon frames. We examine two different methods for estimating the clock skew of an AP. Our first method is based on the linear programming approach, first proposed by Moon et al. in [30] and later used by Kohno et al. in [28]. This method finds a line beacons and the time of arrival of those beacons at fingerprinting node. The slope 4 different APs, we develop a novel heuristic for differentiating frames sent by the fake AP and the authorized one that is being faked. Our heuristic exploits differences both in the beacon timestamp values of different APs as well as the different rate of increment of those values. an AP's clock skew can be used as its fingerprint. In our WLAN setting with predictable beacon delays and high resolution timestamps, we can find clock skews very quickly, using 50 - 100 packets in most cases. We also discuss and quantify the impact of various external factors including temperature variation, virtualization, and NTP synchronization, on clock skew. Very importantly, we also explore the possibility of engineering clock skews to allow a fake AP to generate the clock skew of the original one. Our exploration results indicate that the use of clock skews appears to be an efficient and robust method for detecting fake APs in WLANs. are : fingerprint frames transmitted by the fake AP are interspersed with the frames transmitted from the the authorized AP that is being faked, both of these methods fail to determine clock skews accurately. These methods are not even designed to handle this scenario. To achieve separation of frames with the same identifiers but from For our experimentation and evaluation, we implement our methodology on laptops running Linux and measure the clock skews of a wide range of APs from different manufacturers in three different residential settings. We also use WLAN traces from the 2004 ACM Sigcomm conference to compute the clock skews of the APs used at the conference venue. From our experiments, we find that an AP's clock skew remains consistent over time but the clock skew varies across APs. Therefore fingerprint. virtualization, In a real deployment, we expect our methodology to be implemented on the WIDS nodes. In order to verify whether or not an AP is genuine, a WIDS node can compute the clock skew of the AP and compare with the precomputed clock skew of the AP with the same identity (e.g., MAC address). The main contributions of this thesis are: • We explore the use of clock skew of a wireless local area network access point (AP) as its fingerprint to detect unauthorized APs quickly and accurately. 5 setting. APs. discussed in Chapter 7. We conclude the thesis in Chapter 8 by summarizing our work and indicating directions for future work. 5 We verify our method for several APs in three residential settings and in a large conference setting . • We compare two methods for this calculating clock skew - one based on linear programming and the other based on least square fit. We also supplement these methods with a heuristic for differentiating original packets from those sent by the fake APs . • We improve the resolution of received timestamp of the frames and show that with this enhancement clock skews can be estimated accurately using 50-100 packets in most of the cases. We also discuss and quantify the impact of various external factors including temperature variation, virtualization, clock source selection and NTP synchronization on clock skews. The rest of this thesis is organized as follows. We survey the existing work on detecting unauthorized APs in Chapter 2. Chapter 3 describes the threat model that we address in this thesis. We describe our clock skew estimation methodology in Chapter 4. Chapter 5 contains a description of our implementation and Chapter 6 contains our experimental results. Fabrication of clock skews is WORK unauthorized wireless hosts, who can now become part of the network and launch different types of attacks. In contrast, a fake AP is set up by a malicious attacker to masquerade as an authorized AP. In this thesis, we focus on fake APs. Currently there are two main methods for detecting rogue APs - one that monitors wireless networks either manually or in an automated fashion by sniffing wireless frames to detect rogue APs based on MAC address, BSSID, and SSID based filtering [3, 9, 11, 16, 17, 19], and the other that monitors IP traffic to differentiate wireless network access from wired access using interpacket delay patterns [22, 29, 34]. However, these approaches are ineffective in detecting fake APs mainly because all of the identity fields (e.g., MAC address) can be easily spoofed. al. and the fake AP are active at the same time. Bahl et al. [20] also suggested the use of a location detection algorithm to detect the fake AP if the authorized AP is inactive at the time of detection. The accuracy of this method depends on the accuracy of CHAPTER 2 RELATED WORK For understanding the related work on detecting unauthorized APs, we first distinguish between rogue APs and fake APs. A rogue AP is set up by some naive user for convenience and higher productivity [3, 4, 11, 17]. If this AP's security is not carefully managed, this seemingly innocuous practice opens up the network to Currently ssm Bahl et a1. [20] proposed a method to detect fake APs by monitoring the anomaly in the monotonicity of the 'sequence number' field of beacon frames sent by the authorized AP and the fake AP which is masquerading as the authorized one. However, this method can only detect the presence of a fake access point. On the contrary our scheme can detect and separate out packets from fake AP. Another serious drawback of this method is that it will work only if both the authorized AP a1. MAC device fingerprint fingerprinting faster, timestamps. 7 the location detection algorithm. If the fake AP operates at a location that is very close to the authorized AP's working location, then this location detection method will be ineffective. Our solution removes these constraints and detects unauthorized APs in realistic scenarios. Yin et al. proposed a method for detecting rogue APs that also act as layer 3 routers. However, this work is also vulnerable to MAC spoofing. Franklin et al. [25] introduced a technique to fingerprint wireless device drivers. However, an attacker can also use fake APs with the same wireless device drivers by choosing the same model and the same manufacturer as the original one to evade detection. Our use of clock skew to fingerprint a remote device is not new. Kohno et al. [28] have already shown that clock skew can be used as a reliable fingerprint for a device. However, our contribution is significant because we apply the clock skew based fingerprinting to a scenario where the detections are much faster , accurate and less vulnerable to spoofing attacks compared to Kohno et al.'s original scenario that uses TCP timestamps. the measures AP. facilitate adversary i.CHAPTER 3 THREAT MODEL An adversary can set up an unauthorized AP to masquerade as an authorized one. There are two scenarios in which a fake AP can operate: • The fake AP and the authorized AP that is being faked are both active at the same time. As the current AP selection mechanisms use signal strength as the only selection criterion, the user will select the fake AP if he/she measures the fake AP's signal strength to be higher than the original AP . • Only the fake AP is active and the authorized AP being faked is inactive. This can happen when the authorized AP has failed on its own or due to a Denial-of-Service attack from the adversary, or when the user moves to a location where only the fake AP is reachable. The adversary can facilitate this by tracking and following the user. In our threat model, the adversary is powerful enough to modify any of the MAC address, BSSID and SSID fields of any frame he/she wants. The adversary can also capture, collect and analyze any amount of data without being detected even before actually trying to break into the network. If the packets are sent across the network in encrypted form, the adversary can gather enough packets needed to launch password guessing attacks. It can also decrypt the packets once it succeeds in guessing the password. Our methodology will address the detection of unauthorized APs in all these cases. As our method is based on a physical characteristics of the AP (i .e., the clock skew), it can detect MAC, BSSID and SSID spoofing, whether the authorized WIDS WIDS timestamps 9 AP is active or not. We expect the clock skew based methodology to be deployed in the WrDS nodes for detecting unauthorized APs in WLANs. We assume that the adversary cannot break into WrDS nodes. We also assume that the attacker does not have access to any custom hardware that can generate fake timestamps at a very fine granularity. We discuss this issue in more detail in Chapter 7. CHAPTER 4 METHODOLOGY WLAN), are two methods that a client station (STA) may use to find an AP in the WLAN [2]- frames. listening incremented once every microsecond. 10 Timestamp Capability Info CHAPTER 4 METHODOLOGY In an IEEE 802.11 infrastructure wireless local area network (WLAN) , there are two methods that a client station (STA) may use to find an AP in the WLAN [2] . • Active Scanning: The STA sends a probe request frame to determine which APs are within range. The APs in the vicinity then reply back with probe response frames . • Passive Scanning: The STA learns about the APs in the WLAN by listening to the beacon frames broadcast by the APs. The probe response and the beacon frames both have an 8 byte timestamp as shown in Figure 4.1. The timestamp field contains the value of Timer Synchronization Function (TSF) timer of the AP when it sends the frame. The beacons are scheduled to be sent at periodic intervals by the APs. The timestamps in the beacon frames do not get affected by the random medium access delays of the wireless medium as hardware sets the timestamp value just before actual transmission. The TSF timer is a 64 bit timer which is initialized at the time of starting the AP and microsecond. o 8 12 Beacon !capability Interval Figure 4.1. Structure of fixed fields in beacon/probe response frame 11 estimate fingerprint. fixed frequency. the frequencies due to the limited mechanical accuracy of the cutting process [1]. This is the primary reason behind the existence of clock skew even between seemingly similar clocks. fingerprinter n i t h T{ U fingerprinter it h Si i t h Ri which i t h beacon frame is sent. Therefore, the time, according to the AP's clock, when the fingerprinter receives the packet is + Si/Ri. Let our estimated offset for the i t h frame be denoted Oi and the time difference between the first received frame and the i t h frame according to the fingerprinter's clock be X{ . Then, Xi = U-ti ol = ({Ti + Si/Ri) - {Tx + Si/Ri)) - (U - «i) 2]. Si/Ri - S\/R\. This yields, Oi = ( T i - T 1 ) - { t i - t l ) (4.3) (xi, o^, Our solution uses TSF timestamps in beacon/probe response frames to estimate the clock skew of an AP and uses the clock skew as the AP's fingerprint . An access point's (or regular computer's) clock consists of primarily two parts - • Oscillator: An oscillator is controlled by a crystal and it ticks at a fixed frequency . • Counter: A counter keeps track of the number of ticks produced by the oscillator. The exact frequency of a crystal depends primarily on the type of the crystal and the angle at which the crystal was cut relative to its axes. However, in reality, even two crystals of the same type and of the same cut will have slightly different 1] . Let us assume that a fingerprinter node (a WIDS node) has received beacon frames from a particular AP. Let the timestamp in the ith beacon frame be ~ and let ti be the time in microsecond when the finger printer receives the ith beacon frame. Let be the size of the ith beacon frame and let be the data rate at ith fingerprinter Ti + Sd Ri. ith 0i ith fingerprinter 's Xi . (4.1) (4.2) In most of the cases the beacon frames are sent at a fixed data rate and the size of the beacon frames remain fixed as well [2] . So we can assume that Sd ~ = Stl RI . This yields, (4.3) Now, if the clock skew of a particular device remains constant and if we plot (Xi, Oi), we will get an approximately linear pattern. The clock skew can be estimated as x\,Oi),..., (xn,on) offset-set Sx + 0, 6 0 outputs <5, estimation, 8, = 1... 8.Xi + </>>Oi, (4.4) and the following function is minimized: n l/n.Y,(5-Xi + <l>-Oi) (4.5) i=l the 12 the slope of this linear pattern. Let us call the set of points (Xl , 01) ' .. . , (Xn, On) the clock offset-set of the AP. We evaluate two different methods for estimating the clock skew from the offsetset - a linear programming based method (LPM) that was proposed in [30] and later used by [28] and a least square fit (LSF) method. 4.1 Linear Programming Method (LPM) LPM finds a line ox + ¢, where 0 is the slope of the line and ¢ is the y-axis intercept, that upper bounds the points in the clock offset-set of the AP and outputs the slope of the line, 0, as the clock skew estimate. So, our clock skew estimation, 0, is such that, Vi = 1 . .. n, (4.4) and the following function is minimized: lin. 2:)O.Xi + ¢ - Oi) (4.5) i=l This problem can be solved using linear programming methods for two variables. The LPM method minimizes the effect of any unpredictable delays as it has higher tolerance towards outliers. The clock skew estimate remains stable even if there are significant number of outliers. However, in our case there are fewer outliers because no significant random delay is involved in the communication path and the TSF clocks have a higher precision than TCP timestamp clocks. Interestingly, LPM's nature to tolerate the outliers may cause a serious security problem in our context. If an adversary is able to mix small number of beacons from a fake AP with the beacons of the authorized one it is faking and if the clock skew of the fake AP is close to the clock skew of authorized one, then this method might consider the fake AP frames as outliers and estimate the clock skew of the authorized AP as the clock skew of the set. In this case, it will be difficult to detect the fake AP by comparing the clock skews. (x\, O i ) , . . . , (xn, on), + 5 0 n £ 0i {5.x, 0))2 (4.6) i=l remains minimum. The slope of the line, 8, is estimated as the clock skew of the clock offset-set. One of the major differences of LSF from LPM is its lack of tolerance towards outliers. Even if there are only a very few outliers, the clock skew estimated by LSF will vary significantly from the clock skew determined by the majority of the points. This can cause problems while estimating clock skew from noisy data. Kohno et al. [28] decided not to use LSF for estimation of TCP clock skew because TCP segments can undergo random delays in the network that can affect the accuracy of the clock skew estimate. However, as mentioned earlier, in our case, the absence of any unpredictable delays make the number of outliers insignificant. Therefore, we can use the LSF to estimate clock skews effectively. LSF has an advantage over LPM in the scenario where an adversary tries to avoid detection by interspersing frames from a fake AP with the frames from the authorized one as described above. LSF's sensitivity to the presence of even a small number of outliers will help determining We measure and compare the effectiveness of these two methods in estimating clock skews in Chapter 6. 4.3 Differentiating Frames of Fake APs 13 4.2 Least Square Fitting (LSF) We can also use LSF to estimate the clock skew of an AP from its clock offset-set. Given an offset-set (Xl, 01)' .. . , (Xn, On), LSF finds a line 15x +¢, where 15 is the slope of the line and ¢ is the y-axis intercept, such that L (Oi - (15.xi + ¢))2 (4.6) i=l remains minimum. The slope of the line, 15, is estimated as the clock skew of the clock offset-set. One of the major differences of LSF from LPM is its lack of tolerance towards outliers. Even if there are only a very few outliers, the clock skew estimated by LSF will vary significantly from the clock skew determined by the majority of the points. This can cause problems while estimating clock skew from noisy data. Kohno et al. [28] decided not to use LSF for estimation of TCP clock skew because TCP segments can undergo random delays in the network that can affect the accuracy of the clock skew estimate. However, as mentioned earlier, in our case, the absence of any unpredictable delays make the number of outliers insignificant. Therefore, we can use the LSF to estimate clock skews effectively. LSF has an advantage over LPM in the scenario where an adversary tries to avoid detection by interspersing frames from a fake AP with the frames from the authorized one as described above. LSF's sensitivity to the presence of even a small number of outliers will help determining the fake AP in the above scenario more effectively than LPM. So, it will be difficult for the adversary to masquerade frames from the fake AP as outlying data when LSF is used to estimate the clock skew. We measure and compare the effectiveness of these two methods in estimating clock skews in Chapter 6. Separation of the clock offset-sets of the fake AP(s) and the authorized AP (if present) helps us to gain insight about the fake APs. For example, if the attacker uses multiple fake APs to fake one authorized AP, we can detect the fake APs by separating the clock offset-sets. However, the main drawback of GHT is that it is computationally intensive and requires a large amount of storage. Even though techniques like Randomized Hough Transform (RHT) [35] try to minimize these effects, the time required by these techniques is still quite high. The use of GHT is justified in the domain of image processing and computer graphics because images normally contain large number of edges and GHT can detect all of them together. However, in our case we expect to have very few lines. algorithm requires the initial parameters to be guessed and the accuracy of the results depend on the values of those initial parameters. Furthermore, EM requires multiple iterations to converge. specific assumptions. In our problem domain, we have some specific characteristics of the data that help us to create a less complex and lightweight solution. We know the following facts about the clock offset-sets. the APs. jumps 14 The general problem of fitting multiple lines to a data set is not new. In the domain of computer vision and image processing, Generalized Hough Transform (GHT) [27, 21] is a well-known technique that can be used for this purpose. to have very few lines. Another approach to solve the problem of fitting multiple lines to a data set is to model the data as a mixture model and apply the well known statistical method of expectation maximization (EM) to separate the data [24]. However, the EM converge. We note that the complexities and the computation intensiveness of these algorithms arise from their attempt to solve a general problem without any domain characteristics sets . • The thickness of the lines in the clock offset-set plot (i.e., the variance of the points in the set) remains mostly constant across the APs . • The amount of noise in the data is negligible. Keeping these facts in mind and borrowing ideas from both of the above mentioned methods, we design a lightweight heuristic that solves our problem efficiently. Our heuristic relies on the fact that if a clock offset-set is calculated from the beacons received from different APs, then the clock offset-set will contain certain (i.e., sudden big changes in the value) at the boundary where one packet is We Ay xi,yi) xj,y.j). Ay - Ay = \yt -Vj\/\xi -Xj\ (4.7) \x\ x. jump consistent increment. (xi,yi) (xj,yj) A ^ > groups based on the jumps taken. WLAN on or tune the count field. The value of threshold can be estimated empirically from the clock offset-set of a single AP. Algorithm 2 describes the algorithm for finding the threshold value from the test data. wide variety of datasets. Our results show that the value of threshold estimated by timestamps. For example, if we use our modified MadWifi driver, described later in Chapter 5, then the threshold is estimated as 0.003, whereas if we use jiffies2 to estimate the timestamp then the value of threshold becomes 0.05. 2jiffies is a variable maintained and incremented once in every 4 ms by the Linux 15 from one AP and the successive packet is from another AP. Our heuristic identifies these jumps and differentiates the data based on it. \-Ve exploit this fact to differentiate packets from different APs. Let l:!.ij be the relative skew between two samples in the clock offset-set, (Xi, Yi) and (Xj, Yj)· l:!.ij is defined as follows: (4.7) where Ixi is the absolute value of We introduce a tunable parameter called threshold to differentiate between jump and Thus, two consecutive points Xi, Yi) and Xj, Yj) in the clock offset-set are considered to be a jump if and only if l:!.ij > threshold. Using this definition of jump we can segregate the clock offset-set data into separate In Algorithm 1, threshold is the only parameter that can be and must be tuned. A limit can also be imposed on the count field to filter out small number of outliers that are not part of any data set. However, we do not expect the \-VLAK samples to contain outliers that are not part of any sample and hence we do not set any limit We estimate the threshold using Algorithm 2 from different test data sets. We find that the threshold estimated from a very small amount of data (i.e., 50-100 packets depending on the received timestamp resolution) is enough to separate a the test data depends on the method we use to generate the receiver's timestamps. jiffieS2 2jiJfies kernel. set accumulator[0}.dataset <= [(#1,2/1)] accumulator[O].currentjpoint <= (x\,yi) accumulator[0}.current-.offset <= 1 accumulator'[0].count <= 1 for i 2 to n do do 4= j].current-off set Ajfc < threshold xi7yi) j accumulator [j].<= j}.count + accumulator[j].currentjpoint <= (xi,yi) accumulator[j].currents f f set <= i for A ^ < p p.dataset 4= [(xi,yi)} count 1 currentjpoint <^= (xi,yi) currentsf f set ^= i offset-finalthreshold •<= 0 each test data set do threshold <^= A12 i=3 to n do A ^ _ i ) > threshold threshold 4= A ^ _ i ) > finalthreshold finalthreshold 4= threshold finalthreshold threshold Algorithm 1 Separate clock offset-set points based on originating AP O].dataset ¢= [(Xl, Yl)] O]. currenLpoint ¢= (Xl, Yl) O].currenLo f f set ¢= accumulator[O].count ¢= 1 i = do for each entry j in accumulator do k ¢= accumulator[j].currenLof f set if 6.ik ~ then add (Xi, Yi) to data set of accumulator entry accumulator[j] .count ¢= accumulator[j].count + 1 j] .currenLpoint ¢= (Xi, Yi) j] .currenLof ¢= end if end for if none of the entry in accumulator satisfies ( 6.ik ~ threshold) then add a new accumulator entry dataset ¢= [(Xi, Yi)] p.count ¢= p.currenLpoint ¢= (Xi, Yi) p.currenLoffset ¢= end if end for 16 output number of entries in accumulator as number of different data sets output the data sets of accumulator entries as different data sets from the APs Algorithm 2 Calculate threshold from test clock offset-set f inalthreshold ¢= 0 for do ¢= 6. 12 for 3 do if 6.i (i- l ) ~ then ¢= 6.i (i-l) end if end for if threshold ~ f inalthreshold then finalth reshold ¢= threshold end if end for output finalthr eshold as final calculated threshold 17 Once the datasets are separated using the above heuristic, we can use either LPM or LSF based methods to estimate the exact clock skew of different fake APs. We times-tamps, TravelMate 55AG, and a Intel PRO/Wireless 3945ABG. The Linksys card uses an Atheros chipset that works with the MadWifi driver. We chose these cards because they both support the monitor mode and also because their drivers are open source. The availability of the source code allows us to modify the drivers to measure the arrival time of beacon frames with higher resolution as described below. As the success of our methodology is closely tied to how precisely we can measure time, most of our implementation effort targets obtaining high precision time measurements. We will focus on this very aspect of our implementation in the rest of this section. tcpdump in the system, we note that the timestamp generated by tcpdump includes variable processing time of the operating system. Therefore, use of tcpdump timestamp is not suitable for our purpose. MadWifi CHAPTER 5 IMPLEMENTATION 'vVe implement our methodology for capturing beacon frames, recording timestamps, and computing clock skews of APs, presented in the last section, on two laptops - an Acer Travell'vIate 2303 NLC running Ubuntu Linux 7.4, and an Acer Aspire running SUSE Linux 10.1. We use two wireless cards - a Linksys WPC l'vIadWifi vVe In order to accurately estimate the clock skew of an AP, we need to precisely measure the time when a beacon frame reaches the wireless LAN card of the fingerprinter. We will now describe and discuss three different mechanisms that we explore for the purpose of accurately measuring the arrival time of a beacon frame at the fingerprinter. We first explore the use of sniffers such as [18], to find the arrival time of a frame. Even though this mechanism does not require any changes Next, we explore using the Prism monitoring headers in the l'vIadWifi driver [6] and the Intel 3945ABG driver [5]. These drivers allow additional Prism monitoring by the wireless cards. However, we find that the precision of the time reported by Linux, MadWifi driver puts the current value of the jiffies variable in the timestamp field, jiffies is a counter incremented at regular intervals by the Linux kernel through timer interrupts. By default, it is incremented once every 4 ms in recent Linux kernels (newer than 2.6.13). This interval is a configurable parameter that can also be set to 1 ms or 10 ms [15]. Therefore, the highest resolution available for incrementing jiffies in Linux is 1 ms. Making the jiffies counter arbitrarily small is not desirable because the number of timer interrupts being invoked per second depends on this value and will increase significantly. High timer interrupt overhead can lead to unstable system behavior. Now, as noted before in Chapter 4, the TSF counter in the AP is incremented once every microsecond. Therefore, the clock skew of an AP cannot be estimated quickly and accurately with a 1 ms precision clock at fingerprinter's end. or the IPW 3945 ABG drivers receive a frame, the current value of the TSF timer of the fingerprinter is stored in the timestamp field of the Radiotap header [6, 5]. Both these drivers maintain a microsecond resolution TSF timer. However, this TSF timer is synchronized to the timestamps of the received beacon frames. Therefore, it cannot be used for an accurate measurement of the clock skew. We modify both the drivers to call do-gettimeofday, which supports microsecond resolution, each time a frame is received and store the timestamp in the 8 byte timestamp field of the Radiotap header. We show in Chapter 6 that using this improvement clock skews can be estimated accurately by examining 50-100 packets in most of the 19 headers to be added to frames arriving at the wireless card which has a 4 byte timestamp field. The drivers use it to report the time when the packet is received MadWifi is not accurate enough to detect the clock skew quickly and accurately. In timestamp field. jiffies depends on this value and will increase significantly. High timer interrupt overhead can lead to unstable system behavior. Now, as noted before in Chapter 4, the TSF counter in the AP is incremented once every microsecond. Therefore, the clock skew of an AP cannot be estimated quickly and accurately with alms precision clock at fingerprinter's end. The 1 ms resolution limitation of jiffies leads us to explore a third mechanism. Here, our goal is to use a microsecond precision timestamp. However, a microsecond precision timestamp will quickly overflow a 4 byte field that the Prism header allows and has room for. To deal with this problem, we use another header called the Radiotap header that has an 8 byte timestamp field. Normally, when the MadWifi fingerprinter do_gettimeofday, field do-gettimeofday ioctl feature 20 cases. We end this section by analyzing the overheads caused by our monitoring scheme. The use of dO_gettimeofday in our scheme does not add any significant performance overhead because timestamps are recorded only when a wireless card is in the monitor mode and the Radiotap headers are enabled. Moreover, we also introduce an ioetl system call to turn this feature on or off allowing us to turn off this feature when we are not measuring clock skews. As the packet capture for measuring skew only takes small amount of time (2-3 minutes), the overhead due to enabling this feature only for that duration is not significant. adapters, were used for wireless sniffing. The details of the data collection settings can be found in [33]. As the Sigcomm dataset represents a heavily used 802.11 wireless network, we use it to estimate the number of frames needed to estimate the clock skew accurately in a loaded network. Kohno et al. [28] performed extensive measurements to show that clock skews of networked devices remained consistent over a long time. Our main goal here is to verify that this observation holds in case of APs as well, and measure how quickly and accurately we can estimate the clock skew of APs. We setting last traces on multiple days in same residential settings to verify the consistency of AP fis/s: quantify CHAPTER 6 EXPERIMENTAL RESULTS We use experimental traces from two very different settings to test our methodology for detecting unauthorized APs. Our first set of traces are from data collected during the ACM Sigcomm 2004 conference [33]. The Sigcomm conference network comprised 5 different APs. Five PCs, each with three Netgear WAG 311 wireless estimate 'vVe obtain our second set of traces by collecting wireless data in three different residential settings each with multiple APs operating simultaneously. One residential setting (residential setting A) has 8 APs and two other ones (residential setting B and residential setting C) has 21 APs and 12APs respectively from different manufacturers. We use two laptops that implement our measurement methodology, as described in the la.st section, to collect the packet traces. We collect the packet clock skews over time. We use the measure parts per million, essentially J1sj s, denoted ppm, to quantify clock skew. We describe the results of our experiments with the Sigcomm and the residential traces in the following subsections. Each packet in the Sigcomm traces has a prism header that contains receive timestamp of that packet. As stated in Chapter 5, the timestamps in Prism headers are in terms of jiffies. We also note in Chapter 5 that the resolution obtained with jiffies is in milliseconds3. Therefore, the Sigcomm data do not contain very-precise time measurements in comparison to the data we collect with microsecond nat, 51.25 51.09-51.37 of our procedure, i.e., what is the minimum number of packets that we need to examine to get a close skew estimate. We start with the skew estimates for the first 100 packets and then increment the number of packets by 100 and measure the clock skew in each of the cases. The skew estimate results are shown in Table 6.1. 51.09-51.37 Later, 3As the Sigcomm trace was collected in 2004 (when 2.4 Linux kernels were latest ones), we assume that the resolution of jiffies is 10 ms. However, this assumption does not have any effect on the consistency of an AP clock skew or on the comparison between the clock skews of different APs. only helps us in estimating absolute values of the skews, which are easier to comprehend than comparing them using their ratio. 22 6.1 Results from the Sigcomm Trace Each packet in the Sigcomm traces has a prism header that contains receive timestamp of that packet. As stated in Chapter 0, the timestamps in Prism headers are in terms of jiffies. We also note in Chapter 5 that the resolution obtained with jiffies is in milliseconds3 . Therefore, the Sigcomm data do not contain very precise time measurements in comparison to the data we collect with microsecond resolution. However, the Sigcomm data can still be used for estimating clock skews, albeit using more samples. First to check the consistency of the AP clock skew over time, we create 20 equal sized sample data sets by selecting blocks of packets starting from random offset from the trace collected by the machine chihuahua and measure the clock skew of a particular AP, with SSID sigcomm-nat, for each data set. We find that the clock skew estimate remains around 5l.25 ppm (using LPM) and between 5l.09-5l.37 ppm (using LSF) for each of the sets. This reaffirms that the clock skew of an AP remains consistent over time. Next, we try to figure out the speed of convergence 6.l. As we can see in Table 6.1, the minimum number of packets needed to converge to a clock skew is 300 (using LPM). However, when we use LSF, even 600 packets are not enough to converge to a small range of clock skews. In fact 900 packets (not shown in the table) are required to converge to the 5l.09-5l.37 range. Later, we will show in Chapter 6.2 that LSF can also estimate clock skews accurately using the same number of packets as LPM if we use the higher resolution receiver timestamps. To verify if the clock skew estimated by monitoring 300 packets using 3 As It LSF) ppm ppm ppm ppm 51.21 ppm ppm ppm ppm ppm ppm ppm ppm 300 e., can estimate skews much faster. 52.0 •g 51.6 o O 2 51.4 CO E w m 51.2 0 10 35 Experiment No nat chihuahua. T J I I 1 -L Table 6.1. Skew estimates for samples containing beacon frames sent by sigcomm-nat (collected by chihuahua) with different sample sizes. Packets examined skew( using LPM) skew( using LSF) 100 49.36 ppm 42.73 ppm 200 50.69 ppm 46.14 ppm 300 51 .21 ppm 47.98 ppm 400 51.21 ppm 48.42 ppm 500 51.21 ppm 49.06 ppm 600 51.21 ppm 49.32 ppm 23 LPM remains consistent over time, we take 32 random samples, each of size 300 packets, from the trace and we estimate the clock skew for each sample. Figure 6.1 shows the estimated clock skew as a function of the experiment number. We find that all the estimates remain very close to 51.25 ppm which is the actual estimate of the skew made over all the packets (shown by the dashed line in Figure 6.1). Thus, we can see that even using lower resolution timestamps (i.e ., jiffies) we can estimate clock skews fairly accurately. However we require 300 or more packets. In Chapter 6.2 we show that using higher resolution timestamp we faster. 52.0,--.- ---,-...,---,--,--.--, 51 .0 L---L_-L.._..L-----"'----L_--'-------' o 5 1 0 15 20 25 30 35 Figure 6.1. Skew estimates of samples containing 300 beacon packets sent by sigcomm-nat by taken at different times by chihuahua. based 6.2 Results from the Residential Traces In laptopl the the nat and public-nat-foyer packets, skew(sigcomm-foyer public-public-packets). nat-foyer public-24 We also examine the skew estimates for different APs based on the time measurement data collected at different machines. The skew estimate results based on data from four different machines are shown in Tables 6.2, 6.3, 6.4 and 6.5. We note that the clock skew estimates differ across different measurement nodes. This observation suggests that we must compare clock skews only from the same measuring node. In this section, we will refer to the Acer TravelMate 2303 NLC laptop as laptopl and Acer Aspire laptop as laptop2. We use the monitor mode supported by the wireless cards in both the laptops for capturing beacon frames and also enable the Radiotap headers in the packets (as described in Chapter 5) that we capture. Table 6.2. Skew estimates from Chihuahua (sigcomm-nat has 20,000 packets and sigcomm-public-2 has 7,500 packets). AP skew( using LPM) skew( using LSF) sigcomm-nat 51.25 ppm 51.20 ppm sigcomm-public-2 48.82 ppm 48.90 ppm Table 6.3. Skew estimates from Kalahari (sigcomm-nat-foyer has 30,000 packets, sigcomm-public-2 has 20,000 packets and sigcomm-public-1 has 1,200 packets). AP skew ( using LPM) skew( using LSF) sigcomm -nat-foyer 44.91 ppm 45.00 ppm sigcomm-pu blic-2 42.69 ppm 42.98 ppm sigcomm-public-1 49.94 ppm 49.34 ppm Table 6.4. Skew estimates from Sonoran (both APs have around 10,000 packets). AP skew(using LPM) skew( using LSF) sigcomm-nat-foyer 34.99 ppm 35.29 ppm sigcomm-pu blic-2 32.59 ppm 32.62 ppm packets). sigcomm-nat-foyer Linksysl and laptop2. sets sets (including Linksysl keeping . B and respectively. laptop2 Linksysl 61.84 Belkinl Netgearl Dlinkl Unknownl 41.61 41.47 4We do not have any control over the amount of wireless traffic generated in these 25 Table 6.5. Skew estimates from Mojave (both APs have around 10,000 packets). AP skew(using LPM) skew( using LSF) sigcomm -nat-foyer 40.30 ppm 40.39 ppm sigcomm-public-1 48.16 ppm 48.21 ppm First, we measure the clock skew of two different Linksys APs (Linksys1 and Linksys2). The packets for this trace are collected using Zaptop2. Figure 6.2 plots the offset-sets for the APs. Next, in order to study the consistency of the clock skews of different APs over time we collect offset-sets from 8 different APs (including Linksys1 and Linksys2) in residential setting A on two different days while keeping all the other parameters (i.e., the time-span of capture etc) same4 . Table 6.6 shows the skew estimates of all APs in residential setting A on two different days using LPM and LSF. As we did not have control over all the APs, manufacturer name is predicted based on the manufacturer specific first 3 bytes of the MAC address. The clock skew estimates measured in residential setting Band C are shown in Table 6.7 and Table 6.8, respectively. Table 6.6. Clock skew estimates in residential setting A as measured from Zaptop2 AP Measurement 1 Measurement 1 Measurement 2 Measurement 2 (LPM) (LSF) (LPM) (LSF) Linksys1 -64.23 ppm -64.10 ppm -64.90 ppm -64.77 ppm Linksys2 -45.69 ppm -45.96ppm -46.94 ppm -46.71 ppm Linksys3 -62.05 ppm -6l.84 ppm -62.77 ppm -62.64 ppm Belkin1 -56.37 ppm -56.57 ppm -56.71 ppm -56.85 ppm Belkin2 -1105.50 ppm -1105.69 ppm -1106.29 ppm -1106.06 ppm Netgear1 -58.08 ppm -57.78 ppm -58.86 ppm -59.25 ppm Dlink1 -47.27 ppm -47.17 ppm -47.80 ppm -48.14 ppm Unknown 1 -40.91 ppm -40.99 ppm -4l.61 ppm -4l.47 ppm experiments. However, the traffic variation does not affect our results. measured laptopl Linksysl MeruNetworksl Networks 1 Unknown1 DLinkl (f) "C C 0 () Q) (f) e () 'E c 1il :;g 0 .:£ () 0 U 0 -5 x103 - 1.0x104 -1.5x104 -2.0 x104 -2.5x104 -3.0x104 0 1 X 108 2 X 1 08 3 x 1 08 4 x 1 08 5 X 1 08 Time from beginning of experiment(in microsec) 26 Figure 6.2. TSF clock offset-sets for two different linksys APs (clock skew estimations are -64.23 ppm and -45.69 ppm). Table 6.7. Clock skew estimates (Using LPM) in residential setting B as measured from laptop 1 AP Clock Skew AP Clock Skew Linksys1 22.53 ppm MeruN etwor ks 1 28.14 ppm Linksys2 17.51 ppm MeruNetworks2 32.53 ppm Unknown 31.66 ppm Trapeze Networks1 23.66 ppm Linksys3 20.67 ppm Trapeze Networks2 11.50 ppm Linksys4 24.95 ppm Dlink2 30.50 ppm Linksys5 23.54 ppm Linksys6 23.21 ppm Unknown 1 42.33 ppm Trendwar 34.28 ppm Unknown2 36.22 ppm Dlink3 12.84 ppm Unknown3 39.28 ppm Unknown5 35.5 ppm DLink1 30.85 ppm Linksys7 27.70 ppm Unknown4 33.26 ppm laptop2 estimate estimate Linksysl 42.01ppm Applel ActionTecl microseconds 300 packets (or more for LSF) for accurate estimation of the clock skew (as shown in Chapter 6.1). This provides almost 20 times improvement over Kohno et al.'s results [28] where on an average, 1000-2000 packets were needed for a correct skew estimation. If we consider average time taken to estimate the skew, using higher precision timestamps in a more predictable WLAN setting takes only 2-3 minutes whereas Kohno et al.'s clock skew estimates performed in a wide area setting with coarser timestamps [28] take about 30 minutes-1 hour to converge. This makes our use of clock skew in the WLAN settings 15-20 times faster. We also make other important observations from these tables. First, clock skews are different for different APs. Second, the clock skew for a given AP is consistent over the two measurements. Third, clock skews obtained using LPM closely match those obtained using LSF. 6.3 Differentiating Frames of Fake APs fingerprinter. 27 Table 6.8. Clock skew estimates (Using LPM) in residential setting C as measured from AP Clock Skew estimate AP Clock Skew estimate Linksys1 -42.Olppm Apple1 -33.35 ppm Linksys2 -21.21 ppm Unknown1 -34.56ppm Linksys3 -35.16 ppm ActionTec1 -32.77ppm Linksys4 -28.04 ppm Microsoft 1 -7.93 ppm Unknown4 -37.54 ppm Unknown2 -31.48 ppm Unknown5 -46.34 ppm Unknown3 -36.08 ppm For all the three tables, we are able to estimate the clock skews accurately by analyzing 50-100 packets in most of the cases. Therefore, we find that microseconds resolution receiver timestamps, that we use in our methodology, results in a big improvement over millisecond resolution receiver timestamps that needed about \Ve obtained using LSF. To simulate the attack scenarios where a fake AP and an authorized AP are active at the same time, we construct synthetic data sets by mixing beacon packets collected in real packet captures from multiple APs. While creating these data sets, we preserve the order in which the packets were received by the fingerprinter. finger the estimated fake APs much faster than LPM.5 These results suggest that when we use LPM, we might miss a fake AP operating at the same time as the authorized AP. This points to a serious problem in using LPM. On the contrary, the skews estimated by LSF are exceptionally large than the actual clock skews of each of the contributing AP. So, by just observing the skew value, we can conclude that some fake APs are active. 5In some cases (e.g., cases 3, LPM estimates the skew to be 0 ppm because some As LPM tries to use highest values in the clock offset set to estimate clock skew, it themselves. Therefore, in these cases, LPM approximates the clock skews as 0 ppm. 28 Table 6.9. Measure of skew from the synthetic data set. Case datasets original skews estimated estimated datasets mixed skew(LPM) skew(LSF) estimated 1 2 62.05,62.47 62.47 4614750000 2 2 2 40.91,48.60 40.91 363843000 2 3 2 60.03,45.69 0 406340000 2 4 2 60.61,1106.31 1106.31 4729570 2 5 3 55.14,60.61,1106.31 0 4256390000 3 As the fake AP and the authorized AP, both have the same MAC address, the finger printer has no way of separating the packets. We analyze the effect of this intermingling on our estimation methods. We also test thc efficiency of our algorithm for separating the packets using these synthetic data sets. Table 6.9 shows that in some cases (e.g., case 1, 2 and 4), the skew estimated using LPM is same as the skew of one of the APs whose packets are intermingled. All skews shown are absolute values. Please note that the skews estimated by LSF are extremely large because of the mixing which helps us to detect the presence of 5 contributing Therefore, when using higher resolution receive timestamps LSF alone can be used to detect fake APs. However, if the receive timestamps are of low resolution, both LPM and LSF should be used. This is because LPM uses fewer packets than 5) of the clock offset set values become extremely large due to the intermingling of packets. finds that the differences between those large values are negligible compared to the values separates separate in% r 3 ro ion - CD sepai - [ packet - red Mean coi : 50 I • i . i i . i . i . i . i • _ 0 20 40 60 80 100 120 140 160 Number of packets examined to estimate threshold 29 LSF to estimate the clock skew accurately. On the other hand, LSF detects the mixing of packets from different sources with a higher success rate than LPM. We apply our packet separation algorithm (Algorithm 1), as described in Chapter 4, to all the five synthetic data sets that we use for Table 6.9 as well as to 10 other synthetic data sets created from traces collected by laptopl. Recall that Algorithm 1 requires a threshold that is used to differentiate between the jumps and the consistent increments of the clock offsets. We calculate this threshold using Algorithm 2 for each data set. Once this threshold has been determined, we use Algorithm 1 to separate out the beacon packets of the fake APs from the ones sent by the authentic ones. We find that, for all data sets, our algorithm accurately predicts the number of APs generating the data and correctly separates the offset-set corresponding to each AP. Algorithm 1 can also be used to separate packets in real-time. Figure 6.3 shows how the accuracy of separation increases with increase in the number of packets used to estimate the threshold. We observe that 75 packets are needed to estimate a threshold that achieves 99% accurate packet separation on average (over the five synthetic traces used in Table 6.9). These separated packets from the fake APs must be ignored by the wireless users. These ~ 0 c 2 ~ c 0 :;::; ~ til a. (]) (/) 1il .::.:. 0 til a. 1:5 ~ 0 (.) c til (]) ~ 100 90 80 70 60 50L-~~-L~~~~-L~~~L-~ o m ~ ~ M 1001m1~1~ Number of packets examined to estimate threshold Figure 6.3. Mean correct packet separation rate versus number of packets examined to estimate threshold. 6.4 Impact of External Factors on Clock Skews hardware. However, from our experiments we find that unlike the virtual machine clocks which normally have higher skew than real machines, as shown by Kohno et al. [28], all virtual APs being emulated on a particular hardware have the same clock skew, and that the clock skew is in the same range as the real AP clock skews. This happens because while sending the timestamp, all virtual APs read from the same hardware timer and send the value unaltered. Virtual APs do not maintain separate virtual clocks. Therefore, all virtual APs using the real hardware clock will have the same clock skew as the real hardware clock. We test with five different APs (three Trapeze networks APs running their default firmware and two Linksys WRT54G APs running the DD-WRT firmware [12]). We simulate four virtual APs on each of the five real APs. Our results, shown in Table 6.10, confirm the above argument. This implies that our methodology can also be used to distinguish virtual APs from real APs. 30 packets can also be used to fingerprint the fake APs and determine their locations. We now discuss the impact of external factors on clock skews. 6.4.1 Effect of Virtual APs Virtual APs use single wireless hardware to simulate multiple APs with different MAC Addresses, SSIDs, and BSSIDs. In this aspect, virtual APs are not much different from virtual machines where multiple machines are simulated on the same maintain t est argument. This implies that our methodology can also be used to distinguish virtual APs from real APs. Table 6.10. Skew of virtual APs AP Virtual API Virtual AP2 Virtual AP3 Virtual AP4 1 23.66 23.66 23.66 23.66 2 17.53 17.54 17.17 17.34 3 28.55 28.56 28.56 28.55 4 32.45 32.46 32.45 32.45 5 21.24 21.28 21.27 21.24 operating gradually. Calculate newskew newskew < <= newskew detected, method thus enables our scheme to compare measured clock skews with a higher precision in comparison to the one used by Kohno et al. [28]. 31 6.4.2 Effect of Temperature It has been shown in existing work [28, 31] that under normal PC operating temperatures the clock skew of a device remains constant within ±1 ppm. It has also been noted [31] that this temperature change can also occur due to varying processor load. However, Pasztor et al. [32] have shown that for small time periods (less than 1000 seconds) the clock skew variance remains less than ±0.1 ppm. The results presented in another existing work [31] also support this observation as the change of clock skew due to temperature variance in their results occurs gradually. Therefore, in order to be able to track any changes in the clock skew of genuine APs and for detecting fake ones in the presence of clock skew variation with temperature, we propose using a "rolling signature" scheme described in Algorithm 3. We propose Algorithm 3 Fake AP detection algorithm newskew if (new skew - currentskew) ~ max skew variance then currentskew -{= newskew AP is original else Fake AP detected. end if that an AP's clock skew must be updated to a new value if the difference between the new measured value and the old value is within a threshold. The nodes that measure clock skews (e.g., WIDS nodes) should collect packets from different APs and executes Algorithm 3 over each 50-100 beacon frame block. Since collection of 50-100 beacon frames typically takes much less than 1000s, we can assume that the clock skew variance due to temperature will cause the consecutive clock skew estimates to differ only by approximately ±0.1 ppm rather than ±1 ppm. This [As, we measure relative skew between two physical clocks, extrapolating the findings of [32], we can set max skew variance to ±0.2 ppm. In our high precision fingerprinter, pair Networksl LAN. WLAN fingerprinter's gettimeofday and type of the clock sources depends on the particular model of the processor available clock source in the PC for tracking timestamps that are reported by the gettimeofday system call. Some common clock sources are described as follows [23]. 32 residential traces, when using the same fingerprinter, all but one paIr of access points (Linksys5 and Trapeze Ketworks1 in Table 6.7) differ by more than 0.2 ppm. 6.4.3 Effect of NTP Synchronization of Fingerprinter's Clock Unlike the approach used by Kohno et al. [28], we do not synchronize the fingerprinter's clock using the Network Time Protocol (NTP) or any other clock synchronization mechanism. Rather, we measure clock skew of an AP relative to the fingerprinter. Our measurement times are expected to be small (2-3 minutes) and the timestamps are measured in microseconds. NTPv4 is accurate within 10 milliseconds over the wide-area Internet and within 200 microseconds over a LAN. The default minimum polling interval for NTP is 64 seconds [13]. However, in our case, as the timestamps are measured in microseconds and the estimates of the clock skews are in the range of 100 ppm, enabling NTPv4 will not provide enough accuracy to make the clock skew estimates independent of the fingerprinter's own clock skew. However, in our problem definition, the fingerprinter (a WIDS node in a WLAK environment) remains the same. So this dependence on the fingerprinter's clock is not an issue in our scheme. 6.4.4 Effect of Fingerprinter's Clock Source Selection As mentioned earlier in Chapter 5, in a PC running Linux, system call provides microsecond resolution timestamps. gettimeofday internally uses PC's internal clock source to generate microsecond granularity timestamps. However, any modern PC normally has more than one clock source. The actual number processor and the motherboard being used in the PC. The Linux kernel chooses the best [23]. • PIT (Programmable Interval Timer): PIT is a timer that can be programmed to deliver timer interrupts at the specified timer frequency. The actual frequency of timer interrupts depends on the hardware architecture. microprocessors the clock device included in almost all ACPI-based motherboards. Its clock signal has a fixed frequency of roughly 3.58 MHz. The device maintains a counter that is incremented at each clock tick. The kernel reads the current value of the counter by accessing an I /O port whose address is determined by the BIOS during the initialization phase. unpleasant events. On the other hand, the high-frequency of the TSC counter is useful for measuring very small time intervals precisely. 33 The slower machines have a tick of roughly 10 milliseconds (100 timer interrupts per second), while the faster ones have a tick of roughly 1 millisecond (1000 or 1024 timer interrupts per second). • TSC (Time Stamp Counter): Starting with the Pentium, 80x86 microprocessors feature a counter that is increased at each clock signal. This counter is accessible through the 64-bit TSC register, which can be read by using the rdtsc assembly language instruction. However, when using this register for timing purposes, the kernel must take into consideration the actual frequency of the clock signal. For instance, if the frequency of the clock is 1 GHz, the Time Stamp Counter is increased once every nanosecond. • ACPI PMT (Advanced Configuration and Power Interface Power Management Timer): Advanced Configuration and Power Interface (ACPI) specification defines common interfaces for hardware recognition, motherboard and device configuration and power management. ACPI PMT is another current I/The ACPI PMT is preferable to the TSC if the operating system or the BIOS may dynamically lower the frequency or voltage of the CPU to save battery power. When this type of frequency scaling occurs, the change in frequency of the TSC counter causes nonmonotonic time values and others unpleasant effects. The frequency of the ACPI PMT does not get affected by these me&suring • HPET (High Precision Event Timer): HPET is a high precision timer chip developed jointly by Intel and Microsoft, which can be found in more recent motherboards [14]. The HPET provides a number of hardware timers 34 signal, replace the PIT. different from gettimeofday to measure clock skew of an AP, we must check whether the same clock source is being used by the kernel for all the measurements. The Linux kernel dynamically selects the most accurate clock source available as the internal clock source for the kernel. The accuracy of certain clock sources can change depending on different conditions. For example, in a particular device, TSC might be initially selected as the clock source for gettimeofday. However, after some time if that device switches to battery power from AC power, the Linux kernel will decrease the frequency of the processor (assuming that the processor supports frequency scaling that has been enabled) to save power. This will cause the TSC to go slower and might result in inconsistent time values. In this situation, the kernel will select some other clock source instead of TSC. Table 6.11 shows the change in clock skew estimates caused by the change of power source. To avoid these scenarios, for all our measurements, we use ACPI PMT clock source as this clock source is available in almost all modern laptops and its frequency does not get affected by external events including a switch to battery power. laptop2 Linksysl 34 that can be exploited by the kernel. The chip includes up to eight 32-bit or 64-bit independent counters. Each counter is driven by its own clock signal, whose minimum frequency is 10 MHz. So, the counter is increased at least once in 100 nanoseconds. In the future, HPET is expected to completely As all these internal clock sources are physically different, they will have different clock skew. As described earlier, our estimates of the AP's clock skew are also dependent on the fingerprinter's clock skew. Therefore, while using timestamps the the the change in clock skew estimates caused by the change of power source. To avoid these scenarios, for all our measurements, we use ACPI PMT clock source as this clock source is available in almost all modern laptops and its frequency does not get affected by external events including a switch to battery power. Table 6.11. Comparison of clock skew estimates of same APs measured from Zaptop2 running on AC power and battery power in residential setting A. AP Skew (AC power) Skew (battery power) Linksys1 -64.23 ppm 272.62 ppm Linksys2 -45.69 ppm 254.10 ppm measured skew) to its own timestamp. Let denote the relative skew of the original AP as calculated by the attacker. Now the attacker can read its own timestamp Ti and try to generate fake sequence of timestamps TFi using the following equation. TFi = Ti + S*Ti 7.1) skew of the original AP (as shown in Table 6.9) and the attacker can be detected6. fabricating Additionally, the sequence number of the received beacons not increase mono-tonically as it should if only one AP is active as shown by Bahl et al. [20]. CHAPTER 7 FABRICATION OF CLOCK SKEWS Our approach to detect a malicious AP is based on the clock skew of the AP. As an AP broadcasts beacon packets, an attacker can also listen to those packets and then calculate the relative clock skew of the AP with respect to its own clock skew. Using this clock skew estimate, an attacker can try to masquerade as the original AP by generating fake timestamps by adding proper offsets (those calculated from the S T Fi (7.1 ) There can be two scenarios where an attacker can try to fake an original AP based on whether the original AP is active at the time of attack or not. If the attacker and the original AP are both active at the same time, the attacker's beacon frames will get mixed with the beacons sent by the original AP. As the attacker cannot control the time when the original AP sends its beacons, some of the beacons from the attacker might reach the receiver earlier than the beacons from the original one and some might reach later. As a result the calculated skew will differ from the detected6 . Now, consider the scenario where only the attacker is active and it is fabricating timestamps by using the relative skew of the original AP that it calculated when the original AP was active. In order to test how accurately the attacker can G will monotonically a1. [20]. of the wireless hardware supported by these drivers allow the timestamp to be set by software. However, these drivers support a mode called the raw packet injection mode, where the drivers can transmit any byte stream as a link layer frame without any modification. Thus an attacker can send beacon frames with forged timestamps using this mode. Even with this capability, an attacker cannot fabricate the original APs clocks skew as we explain below. Frame interval [0,CW] (where CW is the contention window size). the channel is still idle after the random delay, depending on configuration, either the sender does the Request to Send (RTS) / Clear to Send (CTS) handshake and then sends the data, or directly sends the data bypassing RTS/CTS handshake. These two random delays, waiting time for the medium to be free and random back off time before actual transmission, make the exact time between when a wireless frame is handed over to the driver and when it is actually sent unpredictable. Therefore, the forged timestamp used by the attacker will not reflect the actual time of transmission and thus will not result in the same clock skew as that of the original AP. first rfakeap original AP measured by the attacker. We shut down the original AP and run this 36 fabricate timestamps, we examine systems that use the open source MadWifi and Intel 3945ABG drivers. In these systems, channel sensing is done by the wireless hardware for performance reasons. Furthermore, the timestamp in the beacon packets is set by the hardware when it actually transmits the packet. None of injection timestamps In an IEEE 802.11 wireless network medium access control, before sending any frame, the sender is required to sense the channel for any other ongoing communication. If the sender finds the channel to be idle for the Distributed Inter-Frame Sequence (DIFS) duration, the sender delays its transmission by a number of random time slots. The length of each time slot is chosen from the O,If To test the effectiveness of clock skew fabrication quantitatively, we first measure the clock skew of an AP from an attacker PC. The RTS/CTS mechanism is disabled (as we expect the attacker to do so because enabling it will cause even more random delays). We also modify the program [7] to send beacon packets with forged timestamps created by offsetting the attacker's timestamp with the skew of the TBTT). - 5 * 1 0 4 1 . . . . i . . . . i . . . . i . . . . i . . . . I 0 5*107 1.0x108 1 . 5 x 1 0 8 2 . 0 x 1 0 8 2 . 5 x 1 0 ' 37 modified rfakeap program on the attacker PC. We calculate the clock skew of the attacker PC based on the timestamps in the rfakeap beacons. We show the results of our clock skew calculations in Figure 7.1 and 7.2. As expected, we see that the attacker's clock skew using forged timestamps differs significantly from the skew of the original AP. One might be able to design a wireless card in the future that allows beacon timestamps to be directly set by software. We now argue that even when armed with such a wireless card it will be hard for an attacker fabricating the clock skews to go undetected. In an IEEE 802.11 network an AP schedules transmission of a beacon frame every beacon interval. The time instant at which an AP schedules transmission of a beacon is called the Target Beacon Transmission Time (TBTT) . IEEE 802.11 defines time zero as a TBTT. The subsequent TBTT values are multiples of the beacon interval. Now, even though each beacon is scheduled to be sent at a TBTT, the actual time at which a beacon is transmitted depends on the time to process the beacon and the time to acquire the shared medium. en "C C o u Q) en e u ·E c Q) ~ o .>C U o U 5x107 1.0x10B1 .5x10B2.0x10B2.5 x10B Time from beginning of experiment(in microsec) Figure 7.1. TSF clock offset-sets for the original AP (clock skew estimation is -178.83 ppm using LPM). 1 x 1 0 4 0 5*107 1.0x108 1 . 5 x 1 0 8 . 0 x 1 0 8 . 5 x 1 0 8 Time from beginning of experiment(in microsec) actual Let denote this delay. Let T# be the beacon processing delay and Tc be the contention delay in acquiring the wireless medium. Then, + TQ. Note that in systems running the MadWifi and the Intel 3945ABG drivers, the beacon frames are prioritized over data frames. The beacon frames and the data frames have separate hardware queues. Thus, the number of data frames in the data queue has no impact on the actual beacon transmission time. TQ, an addition/substraction operation (as shown in Equation 7.1). These operations must be performed by the embedded processor in the wireless card which will en "C C o u Q) en § -1 x104 ·E .s 5 x107 1.0 x10B1 .5 x10B 2 .0 x10B 2 .5 x10B 38 Figure 7.2. TSF clock offset-sets for the attacker with forged timestamps (clock skew estimation is -35 ppm using LPM). The actual time at which the beacon is transmitted is included in the beacon. Therefore, based on the beacon number and the beacon interval and the actual time of beacon transmission, a receiver (e.g., a WIDS node) can determine the delay between scheduling a beacon and the actual transmission of the beacon. T t his TB Te T = TB + Te. A WIDS node that observes a large number of beacon frames can find the minimum values of T. This minimum value corresponds to the situation where the medium contention time, Te , is minimum. Now, when an attacker armed with the capability to directly set beacon timestamps wishes to fake the clock skew of an AP, it must calculate the actual offset by performing a floating point multiplication and substraction TB TB will increase at least by a few microseconds. This Currently, software 39 increase the Ts value thereby increasing the minimum value of T. For the typical 150-250 MHz processors [10], Ts will increase at least by a few microseconds. This increase in the minimum value of T can be detected at the WIDS node. Currently, a special wireless card that allows beacons timestamps to be directly set by software does not exist. Hence, we cannot verify our argument in a real implementation. WORK magnitude less packets compared to the existing TCP/ICMP based techniques [28]. We also discussed and quantified the impact of various external factors including temperature variation, virtualization, and NTP synchronization, on clock skew. We also explored the possibility of engineering clock skews to allow a fake AP to generate the clock skew of the original one. Our exploration results indicate that the use of clock skews appears to be an efficient and robust method for detecting fake APs in WLANs. makes it difficult to estimate accurate clock skew from beacon timestamps. One of the possible ways to solve this problem can be to make the fingerprinter send probe request packets frequently so that the fingerprintee sends enough probe response CHAPTER 8 CONCLUSIONS AND FUTURE WORK In this thesis, we explored the use of clock skews to detect unauthorized access points in wireless local area networks. We developed a methodology that benefits from higher precision timestamps and higher predictability in a local area setting. We evaluated this methodology using traces from the ACM Sigcomm 2004 conference and two different residence areas. We showed that our high precision skew estimation is an order of magnitude faster and uses an order of magnitude TCP /generate One of the interesting extensions to our work will be to investigate the use of clock skew to identify participating devices in an 802.11 ad-hoc network. In an 802.11 ad-hoc network all the participating devices send beacon frames periodically. However, each device also periodically syncs their clock using the time stamps from beacon frames sent by other participating devices by applying a clock synchronization algorithm which ensures monotonicity of the clock timestamps. This process fingerprinter 41 address packets needed to estimate the clock skew accurately before syncing the clock to any other beacon frame. In future, we will like to further explore this direction. Our current solution addresses the problem of detecting fake APs effectively, but the general problem of finding a noncrypto method to detect MAC address spoofing by any wireless host still remains an interesting open problem. ofstandard lan http://airdefense.http://airwave.PRO/http://ipw3945.net/. atheros http://madwifi.http://rfakeap.tuxfamily.http://rfakeap.http://www.http://www.broadcom.com/collateral/PBOl-WLSE), http://com. http://emills/database/reports/ntp4/ntp4.IA-intel.com/hardwaredesign/hpetspec_l.pdf. http://www.org/. http://www.www.proxim.www.org/. REFERENCES [1] IEEE guide for measurement of environmental sensitivities of standard frequency generators. IEEE Standards Coordinating Committee 27-SCC27- on Time and Frequency, 1995. [2] IEEE Standard 802.11 - wireless LAN medium access control (MAC) and physical layer (PHY) specifications. The Institute of Electrical and Electronics Engineers, Inc., 1999. [3] AirDefense, wireless Ian security, http://airdefense.net. [4] AirWave management platform, http://airwave.com. [5] Intel PRO /Wireless 3945abg driver for linux, http://ipw3945.sourceforge.netj. [6] MadWifi- multiband at heros driver for WiFi, http://madwifi.org/. [7] Raw Fake AP, http://rfakeap.tuxfamily.org/. [8] Raw Glue AP, http://rfakeap.tuxfamily.org/. [9] AirMagnet, http://www.airmagnet.com. [10] Broadcom Product Brief BCM-5354, http://www.broadcom.com/collateral/pb/5354- PBOI-R.pdf. [11] Cisco wireless LAN solution engine(WLSE) , http://www.cisco.com. [12] DD-WRT, http: //www.dd-wrt.com. [13] Network Time Protocol version 4 reference and implementation guide, http://www.eecis.udel.edu/ emills/database/reports/ntp4/ntp4.pdf. [14] lA-PC HPET (High Precision Event Timers) Specification(revision 1.0a), http://www.intel.com/hardwaredesign/hpetspecl. pdf. [15] Linux kernel source code, http://www.kernel.orgj. [16] NetStumbler, http://www.netstumbler.com. [17] Rogue access point detection: Automatically detect and manage wireless threats to your network, http://www.proxim.com. [18] tcpdump, http://www.tcpdump.orgj. [19] ADYA, A., BAHL, P., CHANDRA, R., AND Q I U , L . Architecture and MobiCom [20] BAHL, P., CHANDRA, R., PADHYE, J., RAVINDRANATH, L . , SINGH, M., 14. D . paradigms 714-[22] BEYAH, R., KANGUDE, S., Y U , G., STRICKLAND, B., AND COPELAND, In BOVET, AND CESATI, [24] DEMPSTER, A. P., LAIRD, N . M., AND RUBIN, D. B. Maximum likelihood Statistical Society 1 (1977), 1-38. [25] FRANKLIN, J., M C C O Y , D., TABRIZ, P., NEAGOE, V . , RANDWYK, J. V . , USENIX-SS'06: Proceedings of the 15th conference on USENIX Security Symposium (Berkeley, CA, USA, 2006), USENIX Association, pp. 12- 12. C , 802.Hi. [28] KOHNO, T . , BROIDO, A., AND C L A F F Y , K . C. Remote physical device [29] MANO, C. D., BLAICH, A., LIAO, Q., JIANG, Y., CIESLAK, D. A., C , payload sheer detecting unauthorized wireless hosts through network traffic conditioning. ACM Transactions on Information and System Security [30] MOON, S. B., SKELLY, P., AND TOWSLEY, D. Estimation and removal of or not: revealing hidden services by their clock skew. 43 [19] ADYA, A., BAHL, P., CHANDRA, R., AND QIU, L. Architecture and techniques for diagnosing faults in IEEE 802.11 infrastructure networks. In '04 (2004), pp. 30-44. [20] BAHL, P., CHANDRA, R., PADHYE, J., RAVINDRANATH, L., SINGH, M., WOLMAN, A., AND ZILL, B. Enhancing the security of corporate Wi-Fi networks using DAIR. In MobiSys '06 (2006), pp. 1-14. [21] BALLARD, D. H. Generalizing the hough transform to detect arbitrary shapes. Readings in computer vision: issues, problems, principles, and paradigms (1987), 714--725. [22] BEYAH, R., KANGUDE, S., Yu, G., STRICKLAND, B., AND COPELAND, J. Rogue access point detection using temporal traffic characteristics. In Proceedings of IEEE GLOBECOM (December 2004). [23] BOVET, D., AND CESATI, M. Understanding the Linux Kernel, Third Edition. O'Reilly Media, Inc., November 2005. [24] DEMPSTER, A. P., LAIRD, N. M., AND RUBIN, D. B. Maximum likelihood from incomplete data via the EM algorithm. Journal of the Royal Statistical 39, 1-38. [25] FRANKLIN, J., McCoy, D., TABRIZ, P., NEAGOE, V., RANDWYK, J. V., AND SICKER, D. Passive data link layer 802.11 wireless device driver fingerprinting. In SS'06: USENIX [26] HE, C., AND MITCHELL, J. C. Security analysis and improvements for IEEE 802.11i. In NDSS (2005). [27] HOUGH, P. Method and means for recognizing complex patterns. U.S. Patent 3069654, 1962. [28] KOHNO, T., BRomo, A., AND CLAFFY, K. C. Remote physical device fingerprinting. IEEE Trans. Dependable Secur. Comput. 2, 2 (2005), 93-108. [29] MANO, C. D., BLAICH, A., LIAO, Q., JIANG, Y., CIESLAK, D. A., SALYERS, D. C., AND STRIEGEL, A. RIPPS: Rogue identifying packet slicer (2007). [30] MOON, S. B., SKELLY, P., AND TOWSLEY, D. Estimation and removal of clock skew from network delay measurements. Tech. rep., Amherst, MA, USA, 1998. [31] MURDOCH, S. J. Hot or not: revealing hidden services by their clock skew. In CCS '06 (New York, NY, USA, 2006), ACM, pp. 27-36. [32] PASZTOR, A., AND VEITCH, D. PC based precision timing without GPS. 1 ( 2 0 0 2 ) , 1-10. [33] RODRIG, M . , REIS, C , MAHAJAN, R., WETHERALL, D., ZAHORJAN, J., E . 2 0 0 4 [34] W E I , W., SUH, K., WANG, B., GU, Y., KUROSE, J., AND TOWSLEY, D. Passive online rogue access point detection using sequential hypothesis testing In 9 3 - 1 0 8. [35] Xu, L . , AND O J A , E . Randomized Hough transform (RHT): basic mechanisms, Underst. 57, 2 ( 1 9 9 3 ) , 1 3 1 - 1 5 4. 44 A ., VEITCH , CPS. SIGMETRICS Perform. Eval. Rev. 30, 1 (2002), 1- 10. [33] RODRIG, M., REIS, C., MAHAJAN, R., WETHERALL, D., ZAHORJAN, J., AND LAZOWSKA, E. CRAWDAD dataset of wireless network measurement in sigcomm 2004 conference. [34] WEI, W., SUH, K., WANG, B., Cu, Y ., KUROSE, J. , AND TOWSLEY, D . with TCP ACK-pairs. In IMC (2007), pp. 93- 108. L. OJA, E. algorithms, and computational complexities. CVGIP: Image Underst. 57, 2 (1993), 131- 154. |
| Reference URL | https://collections.lib.utah.edu/ark:/87278/s6zk5x8q |



