anelok: revisiting Bluetooth, summing it up
werner at almesberger.net
Sat Nov 23 15:27:27 EST 2013
Bas Wijnen wrote:
> What I'm seeing from you so far, you are way more hardcore than I am,
Heh, thanks :-)
> Then again, I
> wouldn't have any issue with working at the bit level.
What I wouldn't like about working at the bit level in this case is
the very right timing. The CPU runs at 48 MHz, so you have only 48
cycles per bit and I'd expect that you'd get a lot of noise as well.
All that wouldn't be so bad if the CPU had nothing else to do, but
it also has USB, a display, the wheel, and so on to take care of. It
would be an uphill battle at least.
> 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.
Heh, maybe. But then, the open standards tend to get fixed once they
collect enough bad press. Of course, after that, marketing will
weaken the security again by introducing convenience features. Like
password hints :-)
For those who haven't seen it - it's also a good study of what people
actually do with those password hints:
> 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.
We can always keep that as an option, yes. That's the beauty of making
one's own firmware :)
> 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)?
One may say that they may be what pushes the lazy standards bodies
to actually do something about security. See for example the Logitech
keyboard and mouse devices in Mike Ryan's talk: the encrypt the
"standard" keystrokes because "somebody is watching my keystrokes"
would scare customers. But everything else goes into the aether
> 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.
Data sheet (kl25):
Reference manual (k25rm):
Quick reference (klqr) which is a lot more useful than the name suggests:
The names in parentheses are the abbreviations I use with "dsv".
Here's the BOOKSHELF file:
> In particular, how the integrated peripherals are controlled, and how to
> flash the program into the device. Do you have pointers to such
It uses SWD (Single Wire Debug), an ARM-specific leaner version of
You could piece together how it works but I found it simpler
to just get a FRDM-KL25Z and use that. Works very well.
> If there are cables between all components, what's the added value of
> using bluetooth?
There's none :) It's just that I don't have any other means for
exchanging data between PC and Anelok. Anelok's USB is already
occupied with the USB keyboard. So the only thing left in this
situation is the wireless channel.
> 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. :-)
More information about the discussion