comments on SP 800-121 Rev 1 draft

The following is an email I sent to NIST in response to a request for comments on the draft Guide to Bluetooth Security (NIST Special Publication 800-121 Rev. 1).

Thank you for your efforts to produce and update SP 800-121! Although I have some criticisms, your document is important and unique.

My principal concern about the guide is that the recommended practices are too weak to support the safe use of Bluetooth. Looking at the SP 800-153 draft (Guidelines for Securing Wireless Local Area Networks), I see several recommendations listed in the Executive Summary that would be just as applicable to Bluetooth:

"When planning WLAN security, consider the security not only of the WLAN itself, but also how it may affect the security of other networks."

"Have policies that clearly state which forms of dual connections are permitted or prohibited for WLAN client devices, and enforce these policies through the appropriate security controls."

"Ensure that the organization's WLAN client devices and APs have configurations at all times that are compliant with the organization's WLAN policies."

"Perform both attack monitoring and vulnerability monitoring to support WLAN security."

"Conduct regular periodic technical security assessments for the organization's WLANs."

My second concern is that it is unclear how to implement many of the recommendations. Unfortunately this is more a problem with Bluetooth itself and the available tools than with your document. Along with others in the information security community, I am working to develop Project Ubertooth into a tool that will bridge the gap as much as possible, but more needs to be done.

Third, I have some specific comments and criticisms:

It is incorrect to say that Frequency Hopping Spread Spectrum (FHSS) provides even "a limited level of transmission security." Other features of Bluetooth provide security benefits. FHSS provides interference avoidance.

It is easy to overstate the security benefits of power control. I suggest eliminating discussion of transmit power from the document.

Good job on citing some important work! (Spill/Bittau, Wool/Shaked)

Where you state, "If that device remained discoverable, its location could be tracked by an adversary", it should be corrected to state that discoverability is not required. See Spill/Bittau and this blog post:

http://ossmann.blogspot.com/2011/07/discoverability-is-not-mitigating.html

Table 4-1 is an important contribution that I will recommend to many people.

Section 4.2 "Bluetooth Threats" seems weak. The list of threats is disjointed, inconsistent, and in places dated.

Thank you again for your contribution. I hope you find some of these comments helpful.

Sincerely,

Michael Ossmann
Great Scott Gadgets
mike@ossmann.com
http://greatscottgadgets.com/

Power over Ethernet and the Throwing Star LAN Tap

Since handing out hundreds of Throwing Star LAN Tap printed circuit boards as business cards at DEF CON, I've received a number of interesting questions about the device in my email. A couple people were hoping to use Throwing Stars to monitor connections that use Power over Ethernet (PoE). When I designed the current version of the Throwing Star LAN Tap, I decided to pass all eight conductors through from J1 to J2 (the target ports) even though this necessitated the addition of two filtering capacitors. I did this primarily to support RS-232 monitoring (a feature that I imagine is very rarely used), but I also thought that having eight conductors might be handy for other things such as PoE. It wasn't until recently that I actually verified PoE capability, however.

PoE allows a device to be powered by direct current (DC) running over an Ethernet cable that may also be used for communication. It is popular for VoIP telephones, IP security cameras, wireless access points and other network-connected devices that are commonly deployed at multiple locations within a building. There are several different ways that PoE has been implemented over the years, but most devices these days follow the IEEE 802.3at-2009 standard or its similar predecessor, IEEE 802.3af-2003. I looked at these standards and also at the most common non-standard implementations and found that they are all compatible with the Throwing Star LAN Tap.

Twisted pair Ethernet cables consist of eight wires arranged into four pairs. In some cases two of those pairs are unused. Each pair carries a differential signal with one wire carrying the inverse of the signal on the other wire; when one goes high, the other goes low. This is an alternating current (AC) signal.

What all of the PoE schemes have in common is that they introduce a DC bias between one pair and another. In the figure to the left, the purple and green lines represent the voltage on one pair and the blue and orange lines represent the voltage on a second pair. In each pair, the AC component (the rapidly changing difference in voltage between the two wires) is relatively small. This is the signal that carries network data. From one pair to the second pair there is a larger voltage difference, the PoE DC bias.

The Throwing Star LAN Tap provides a DC path for all eight conductors between the target ports, J1 and J2, but it only extends a subset of those conductors to the monitoring ports, J3 and J4. This is done in such a way that Power over Ethernet on the target network can pass through the tap but does not extend to the monitoring ports. It's almost like I meant to do that. :-)