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: http://zed0.co.uk/crossword/ > 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 unencrypted. > 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): http://cache.freescale.com/files/32bit/doc/data_sheet/KL25P80M48SF0.pdf Reference manual (k25rm): http://cache.freescale.com/files/32bit/doc/ref_manual/KL25P80M48SF0RM.pdf Quick reference (klqr) which is a lot more useful than the name suggests: http://cache.freescale.com/files/32bit/doc/quick_ref_guide/KLQRUG.pdf The names in parentheses are the abbreviations I use with "dsv". Here's the BOOKSHELF file: https://gitorious.org/anelok/anelok/source/BOOKSHELF > In particular, how the integrated peripherals are controlled, and how to > flash the program into the device. Do you have pointers to such > documentation? It uses SWD (Single Wire Debug), an ARM-specific leaner version of JTAG. http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php You could piece together how it works but I found it simpler to just get a FRDM-KL25Z and use that. Works very well. http://www.digikey.com/product-search/en?x=-1303&y=-73&lang=en&site=us&KeyWords=FRDM-KL25Z > 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. :-) Kewl :-) - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
