anelok: revisiting Bluetooth, summing it up

Bas Wijnen wijnen at debian.org
Sat Nov 23 14:15:22 EST 2013


On Sat, Nov 23, 2013 at 06:28:47AM -0300, Werner Almesberger wrote:
> having to work at the bit level is a bit too hardcore even for my
> taste.

I didn't know that was possible. :-P

What I'm seeing from you so far, you are way more hardcore than I am,
and I am considered pretty hardcode by people around me.  Then again, I
wouldn't have any issue with working at the bit level.  That sort of
thing gives rise to problems related to timing which have to be solved
by counting clock cycles of assembly instructions.  Sounds like fun! :-)

On Sat, Nov 23, 2013 at 12:25:18PM -0300, Werner Almesberger wrote:
> First of all the main premises for looking at BT/BTLE at all: I
> assume that, if Anelok supports BT/BTLE radio,
> 
> - there will (*) be a keyboard/HID protocol it can implement, that
> - is sufficiently secure for wireless password entry,
> - does not require special drivers on the PC/tablet/smartphone (like
>   USB HID today), and
> - is likely to become a "standard" choice on such devices (like USB
>   and HID today.)
> 
> (*) Could be "a suitable protocol already exists and is in
>     widespread use", but also "a suitable protocol has been
>     specified and is expected to be widely adopted", or "the usual
>     suspects are expected to come up with a protocol that will then
>     be widely adopted", etc.
> 
> Question to the audience: are these premises correct ?

I don't think so.  Given the industry's track record, I expect that
there will be a very standard system that everyone will use, that is
totally insecure.  For example, I don't expect the BTLE spec to change
when it comes to "None of the pairing methods provide protection against
a passive eavesdropper".  As Mike Ryan said, "they published a spec with
a broken key exchange protocol, and they didn't even say I'm sorry".  I
have no reason to think they intend to fix it.

Which would lead me to think the best thing to do would be to use the
unencrypted link with a proper encryption layer on top of it.  The huge
downside of that would be that it requires host-side drivers.  So
perhaps that's better provided as an option: easy for people who can
physically secure their 10 or so meter environment; hard but more secure
for those who can't.  But it's probably a better idea to require a wired
connection for real security, because that's usually easier than
installing host-side drivers.

Then again, neither host-side drivers nor a wire are an option for
smartphones and the like.  Am I missing something, or is it simply
impossible to do this in a secure way for them (assuming the link layer
will not be secured)?

> Even in the absence of a usable standard let alone implementation,
> we could always use a proprietary protocol at the beginning and
> switch to proper BTLE later. This is not worse that what we'd do
> with a 802.15.4 radio anyway. (I.e., there is not even a
> "HID/keyboard" in 802.15.4 to begin with.) This would have the risk
> of finding roadblocks long after the hardware in question is
> finalized.
> 
> Question to the audience: am I making sense this far ?

Yes.

On Sat, Nov 23, 2013 at 12:53:44PM -0300, Werner Almesberger wrote:
> 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.

I checked the web for documentation about this MCU, but couldn't find a
datasheet with enough information to allow me to actually program it.
In particular, how the integrated peripherals are controlled, and how to
flash the program into the device.  Do you have pointers to such
documentation?

> 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 ?

If there are cables between all components, what's the added value of
using bluetooth?

> 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.

Good to know.  I have several other projects which don't get enough
attention, but something like this might well fit in with one or two of
them. :-)

Thanks,
Bas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20131123/3ad33d75/attachment.pgp>


More information about the discussion mailing list


interactive