Dr. Werner, Much to like about this two-MCU approach. The enhanced security by partioning communication protocol to a dedicated MCU will make Anelok stand head and shoulders above (known) competing password gadgets.
Yes, complexity increases, but that seems manageable. What might I do to help? My resources are modest, but heck I can help out a bit. Feel free to email me if you prefer [email protected] Ron K Jeffries Ron K Jeffries 805-567-4670 mobile On Dec 25, 2014 6:59 AM, "Werner Almesberger" <[email protected]> wrote: > When I stumbled upon the Kinetis KL16 (it's like the KL26, but > without USB and regulator, and has IOs on these pins instead) > a while ago, an old thought came back to me: how about > distributing the tasks currently the sole KL26 handles among > two MCUs ? > > One, let's call it the "secure MCU" (sMCU) would control the > user interface (slider, display, LED), the memory card, and > also control the boost converter (which feeds both display and > memory card). > > The other, let's call it the communication MCU (cMCU) would be > in charge of USB OTG, USB power regulation, and communication > with RF and managing the RF chip (which has another small MCU > inside). > > The two would communicate among each other via I2C. When > something needs to be encrypted, this is done on the sMCU. The > cMCU therefore needs only what I'd call "weak trust", similar > to the RF MCU. Both sMCU and cMCU would normally be > operational, i.e., unlike with the RF MCU, there would be no > hard power-down for any of them. > > > It would address the following major worries: > > - massively lower the risk of bugs in the communication code > (USB, RF) leading to vulnerabilities, > > - increase the total amount of Flash available from 128 kB to > 256 kB (if the cMCU is a KL26) or maybe even 384 kB (if it > is a KL27). > > It would also give the following minor benefits: > > - the communication processor could get its own crystal > specificially for USB, thus eliminating all the tweaks and > tricks I have to do at the moment. > > - programming the cMCU could be opened more easily to 3rd > parties (*), since the cMCU doesn't have to be trusted. This > could be useful in case there are "intellectual property" > issues with some of the communication protocols that would > prevent them from being part of the device as shipped. > > (*) The idea is still that users will be able to admit > firmware for all every bit of Anelok from any source of > their choosing, but having such a separation may make > this choice more practical. > > Drawbacks: > > - two MCUs, even if both are 32-QFN, cost more than a single > one in 48-QFN, > > - slightly increased power consumption (probably negligible), > > - slight increase of software complexity, for the MCU-to-MCU > interface. > > > The general plan is (as it has been) that firmware upgrades > would come mainly from the memory card. So the sMCU would be > self-sufficient in this regard: it could enable power for the > memory card, access its content, ask the user for > confirmation, and read the user's response on the slider. The > only thing missing would be the ability to control USB power. > So if the cMCU refuses to turn on the USB regulator, one would > have to do firmware upgrades on battery power. > > Furthermore, the sMCU would control the SWD interface of the > cMCU. For simplicity, there could also be a boot loader > protocol over the I2C link. When the sMCU sees new firmware > for the cMCU, it would then read the corresponding file from > the card, authenticate its content, and send it to the cMCU. > Likewise, if there is new firmware for the RF MCU, it would > get sent to the cMCU which then in-circuit programs the RF > MCU. > > Developers may choose a role reversal, with the cMCU running a > DFU boot loader and the sMCU running the I2C boot loader. Then > the cMCU could reflash the sMCU. This would of course make the > sMCU less trustworthy, but that's not much of a concern in > this scenary. > > > I kinda like the idea. But that's something for later as it > would require the introduction of a new chip (which I don't > have at home), new PCBs, etc. > > Opinions ? > > - Werner > > _______________________________________________ > Qi Hardware Discussion List > Mail to list (members only): [email protected] > Subscribe or Unsubscribe: > http://lists.en.qi-hardware.com/mailman/listinfo/discussion >
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
