Anelok: one more MCU - maybe an idea for later

Ron K. Jeffries rjeffries at gmail.com
Thu Dec 25 17:37:35 UTC 2014


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

Rjeffries at gmail.com

Ron K Jeffries

Ron K Jeffries
805-567-4670 mobile
On Dec 25, 2014 6:59 AM, "Werner Almesberger" <werner at almesberger.net>
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): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
> http://lists.en.qi-hardware.com/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20141225/b59a8d5e/attachment.html>


More information about the discussion mailing list


interactive