anelok: revisiting Bluetooth, tentative roadmap 2/2

Werner Almesberger werner at almesberger.net
Sat Nov 23 10:53:44 EST 2013


So what changes ? For Anelok, not much at the moment. There are
still other aspects of the design that need working on, even if it's
just for design testing. Namely:

- switching all SPI-capable communication channels (display and RF)
  to actually use SPI (this also require a rework of the two swapped
  OLED signals,

- see how things go when running on battery power. This is the
  biggest "known unknown" this far.

- measure power consumption, especially in idle states, and there
  with particular emphasis on the boost-converted part (converter
  itself, memory card, OLED). The memory card FET probably also
  needs rework.

- access the memory card in 4 bit SD/MMC mode and not just as SPI.

- have some basic GUI to be able to at least show how it would work.
  The underlying crypto can still be weak.

- a bit more USB device and host support, enough for HID in and out,
  would also be nice.

- make a pretty case.

So there's more than enough left to do there before touching RF
again.


However, the BT/BTLE-capable design will have to be evaluated,
especially the clocking options. It makes sense to build a new
evaluation board for this purpose, basically replacing the updated
ATUSB I had thought of making.

Since I expect that standards-compliant and thus interoperable
BT/BTLE support will not be possible until later in the project,
we'll need to have a USB dongle implementing our proprietary variant
to get started. This could of course be the same design as the one
used for evaluation or it should at least try to be very close to
it.


With the idea of our RF dongle being an ATUSB successor gone, it may
no longer make sense for it to even look like ATUSB. Now, we already
have some USB critter in this project, the Y-Box ...

So perhaps the following would make sense: add a BT/BTLE transceiver
with USB-capable MCU and whatever we expect to need for autonomous
pairing (see below) to the Y-Box. The USB-capable MCU would connect
to the currently unused data lines coming from the host. This MCU
would be just another Kinetis L, like the one we have in Anelok, so
most of the software would be identical. This is also what was
planned for the ATUSB update.

Another benefit of combining dongle and Y-Box would be that we'd need
only one host USB port for the pass-through scenario of [1].

Now, since we don't want to need drivers for the host, the dongle
has to appear to USB as nothing fancier than a boring HID device
(with some upgrade capability, most likely DFU) and thus needs to be
able to pair on its own. We may call this "autonomous pairing".

Now, the industry has a proven track record of getting "nice and
simple" pairing terribly wrong, e.g., Wi-Fi WPS [2] and now BTLE
"Just Works" et al. [3, starting at 19:58].

Looking at [4], it seems that any proper and fully autonomous
man-in-the-middle protection would require at least a display or a
"keyboard". Maybe we could make this a little easier, though, by
letting Anelok talk via USB to the MCU in the Y-Box. There would be
no driver issues since we control the software of both.

How does that sound ?


Oh, and there's no reason why I should be the only one having fun.
The enhanced Y-Box would make a nice little sub-project for anyone
interested in playing with that sort of BE/BTLE-capable RF device and
enough "trailblazing" as been done on the MCU side already that this
shouldn't be overly daunting.

- Werner

[1] http://downloads.qi-hardware.com/people/werner/anelok/tmp/comm.pdf
[2] http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/
[3] https://www.usenix.org/conference/woot13/bluetooth-low-energy-comes-low-security
[4] http://padovan.org/pub/bluetooth/bluetooth-security-article.pdf



More information about the discussion mailing list


interactive