Re: New Bihman-Shamir Fault Analysis Paper

There is an inherent conflict between two claims that are
central to the fault-analysis paper(s):
   "the secret key [is] stored in a tamperproof cryptographic device"
and
   "the cryptographic key is stored in an asymmetric type of
    memory, in which induced faults ..."

If the device is truly tamperproof, the attacker should not
be able to induce faults.  Even given susceptable "consumer-
quality" devices, it would be trivial to store the cryptographic keys
in a redundant memory configuration, such as ECC "error-correcting
code" memory that can self-correct a range of failures and detect
a much wider range. It would also seem reasonable to protect the
cryptographic core (algorithms and data) with a digital signature
that would "crash" the device, rather than proceed with incorrect
key information.

My naive reading of the attack suggests that storing the cryptographic
key together with its one's complement would minimize the chance that
an attacker can exploit asymmetric fault inducement.

Finally, I'm curious whether this attack would work on masked ROM
or fusable-link (one-time programmable) PROMs (not EPROMs that have
no reprogramming window). These are more likely to be used in
production devices than EEPROMs, if only for cost-savings.

Martin Minow
minow@apple.com

Martin Minow wrote:
> There is an inherent conflict between two claims that are
> central to the fault-analysis paper(s):
> "the secret key [is] stored in a tamperproof cryptographic device" and
>    "the cryptographic key is stored in an asymmetric type of
>     memory, in which induced faults ..."

> If the device is truly tamperproof, the attacker should not
> be able to induce faults.  Even given susceptable "consumer-
> quality" devices, it would be trivial to store the cryptographic keys
> in a redundant memory configuration, such as ECC "error-correcting
> code" memory that can self-correct a range of failures and detect
> a much wider range. It would also seem reasonable to protect the
> cryptographic core (algorithms and data) with a digital signature
> that would "crash" the device, rather than proceed with incorrect key information.

[snip]

My comment is about the last item here.  Doesn't "crash" assume normal use, and/or
that the device would have to be processed in an expected sort-of thread so that it
would be able to initiate the crash response?