Anelok: "competitor" in trouble

Werner Almesberger werner at almesberger.net
Thu May 29 04:21:16 EDT 2014


Bas Wijnen wrote:
> Sure; I'm just not trusting their protection mechanism, so I treat it as
> nonexistent, which means it is as secure as the other chip.

I think it would be very interesting how you design a cryptosystem
in which nobody ever knows all of the truth and, moreover, is immune
to code injection and such. There are things that go in the
direction you want, but I think you're still be a number of PhDs
ahead of the state of the art with such requirements :-)


What I think you could accomplish is to have multiple MCUs running
in parallel and each doing only a part of the processing, with some
(trusted but simple) arbitration device in the middle. Designing
this would probably make a nice PhD at anelok.edu :-)

You'd then not trust any individual code protection, but you'd
still trust that not all of them are compromised at the same time.

In practical terms, you'd end up with a rather complex system. And
it's very likely that you'd accidentally introduce some new holes.
That's how cryptosystems are broken in real life: the "hard" bits
are only attacked in ivory towers while the underworld, be it
state-run or private, just finds the flaws in how you tie these
"hard" bits together.

By increasing complexity, you just make it more likely for them to
have something to find.


What's sometimes done is a further reduction of the complexity of
the system you have to trust by adding specific "secure" chips. A
common problem with them is that they may turn out to be less so
than you may have thought :)

Although this is often again for system design reasons. Imagine
this showing an imposing fortress:
cdn.scragged.com/content/nonversioned/images/articles/potemkin-village.jpg

Also, they tend to limit you to a very narrowly defined system
design, so if a weakness is found in any of the "secure" bits you
use, you have to discard the whole design and can't just fix it
with a firmware update.


What I'd eventually like to do is to have multiple designs that
implement the same overall system, with different chips. E.g.,
KL26 + CC2543 vs. STM32F2 + nRF51822, or such. If an attack against
one of the combos becomes known, then one can switch to the/an
other. The risk of a product going straight to the competition,
with much fanfare, may also help chip manufacturers to stay honest.

As we can see in the Snowden aftermath, they don't like that sort
of attention a bit ;-)


But let's not get ahead of ourselves. Making one design and doing
it as right as we can is already plenty of challenge.

- Werner



More information about the discussion mailing list


interactive