[Cryptech Tech] goals / use cases

[Peter Gutmann]

Warren Kumari <warren at kumari.net> writes:

>Have we documented the actual threat model anywhere?

No, and this segways with my earlier grumbling about lack of (or at least very
vague) technical requirements.  Since there's no clearly-defined goal, no-one
can ever be right in any requirements debate.  Now no-one can be wrong either,
but it does invite way too much bikeshedding.  I've already given one wish-
list for basic stuff (amount of flash, RAM, etc), but we really need something
where we can say "this ==> meets the design requirements XYZ; if we change it
to that ==> then we no longer meet those goals; therefore we'll go with this".

>Can the attacker get close to the device? How close? While it is operating
>under normal conditions? Can he provide arbitrary data to the device, or is
>his ability to provide input limited? Does he have access to startup keys (a
>token you need to present when turning the device on)? Can he physically
>monkey with it? While it is in operation? Without being noticed?

I would assume no physical access (otherwise you'll need to use something like
tamper-responsive packaging and environmental sensors, which take an awful lot
of work to get right), maybe one-hop-away electrical access (can't plug
something directly into the USB connector but can connect to the device
plugged into the USB connector, leading back to the "do we have to worry about
attacks on the USB subsystem?" question), and so on.  OTOH for the power lines
it's just good engineering practice to provide as much filtering and
protection as you can (when DPA and similar attacks were first published one
particular HSM was totally immune to them, not because they'd gone to great
lengths to counter them but simply because the guys who built it took care to
make the power system pretty robust), so that should be able to ride out power
glitches and spikes and not radiate anything back onto the power source.

[Insert further long list here]

Peter.