1996-11-03 - Re: New Bihman-Shamir Fault Analysis Paper

Header Data

From: Dale Thorn <dthorn@gte.net>
To: Martin Minow <minow@apple.com>
Message Hash: e33442cc5d35255ef1dd0c567a6f391ed9d8f7932d1989d8d980b7d9f31446bb
Message ID: <327C4114.238F@gte.net>
Reply To: <v03007800aea040ab78e7@[17.202.40.158]>
UTC Datetime: 1996-11-03 07:28:18 UTC
Raw Date: Sat, 2 Nov 1996 23:28:18 -0800 (PST)

Raw message

From: Dale Thorn <dthorn@gte.net>
Date: Sat, 2 Nov 1996 23:28:18 -0800 (PST)
To: Martin Minow <minow@apple.com>
Subject: Re: New Bihman-Shamir Fault Analysis Paper
In-Reply-To: <v03007800aea040ab78e7@[17.202.40.158]>
Message-ID: <327C4114.238F@gte.net>
MIME-Version: 1.0
Content-Type: text/plain


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?







Thread