Anelok: one more MCU - maybe an idea for later
Ron K. Jeffries
rjeffries at gmail.com
Thu Dec 25 17:37:35 UTC 2014
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
Feel free to email me if you prefer
Rjeffries at gmail.com
Ron K Jeffries
Ron K Jeffries
On Dec 25, 2014 6:59 AM, "Werner Almesberger" <werner at almesberger.net>
> 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
> 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.
> - 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
> 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
> 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): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discussion