|Informative Information for the Uninformed|
Next: MediumCompare Metric Up: Statistical Analysis of Duration Previous: The Duration Matching Algorithm Contents
SimpleCompare is the first of three related metrics, the other two being MediumCompare and ComplexCompare. SimpleCompare is unique in that it compares the input against a print in the database without using any information about other prints in the database. That means that if a certain duration value is incredibly unique, such as the illegal ones only found in prism2 based implementations, it has no opportunity to take this into consideration.
All the metrics presented in this chapter break the fingerprints up into two different sets of data points. The first set is a set of pairs of the form (duration value, count). The second set is a set of triples of the form (packet type, duration value, count). The diagrams below leave the count component of both tuples out for clarity.
SimpleCompare, as well as the other metrics, has three different flavors. It can be computed using just the (duration value, count) pairs, or it can be computed using just the (packet type, duration value, count) triples. Finally the results from both analyses can be combined. Combining the results of these metrics is simply a matter of adding the return values from both metrics.
The SimpleCompare metric is defined below. The input packet capture is denoted by L. R, on the other hand, denotes a print in the capture database for a particular 802.11 implementation.
sum = 0; for every duration-value d sum += return sum;
The metric weights common durations that appear in their respective prints at roughly the same rate more heavily than ones that do not. However, SimpleCompare doesn't pay attention to duration values that aren't in the intersection, as illustrated in Figure 4.1, even though the number of values not in the intersection is clearly a strong indicator of how close two prints match. It also doesn't have any idea of how unique any specific duration values are across the entire database.
At first, this lack of a global perspective on the relative likeliness of seeing duration values seemed that it would hinder this algorithm significantly. Consider the case when a prism2 sample is input that uses all the same illegal duration values as the one stored in the database, but at very different rates. SimpleCompare lacks the information to realize that the illegal values identify a prism2 implementation, and could grade this sample incorrectly.
At this point, SimpleCompare is also ignoring the packet type in which the duration values appear. This can cause two problems. One is that two different implementations use the same duration value, but in consistently different packet types (probe requests versus association responses for example). The other is that the ratio that duration values are used across all packet types fluctuate largely across packet samples, but the rate is much more consistent when confined to a particular packet type. Both of these problems are addressed by considering the packet types when looking at durations.
We can reuse SimpleCompare except this time we run it against the (packet type, duration) pairs, as illustrated below.
sum = 0; for every pair(packet_type p, duration-value d) sum += return sum;