Anelok: one more MCU - maybe an idea for later
Werner Almesberger
werner at almesberger.net
Thu Dec 25 14:58:39 UTC 2014
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
More information about the discussion
mailing list