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?
participants (2)
-
Dale Thorn
-
Martin Minow