"Bent" keys

"Bob Jueneman" <bjueneman@novell.com> Mon, 11 June 2001 23:06 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20526 for <pkix-archive@odin.ietf.org>; Mon, 11 Jun 2001 19:06:52 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BMArN18808 for ietf-pkix-bks; Mon, 11 Jun 2001 15:10:53 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BMAoJ18804 for <ietf-pkix@imc.org>; Mon, 11 Jun 2001 15:10:51 -0700 (PDT)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 11 Jun 2001 16:10:40 -0600
Message-Id: <sb24ed80.019@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 11 Jun 2001 16:11:18 -0600
From: Bob Jueneman <bjueneman@novell.com>
To: ietf-pkix@imc.org, marcnarc@rsasecurity.com
Subject: "Bent" keys
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f5BMApJ18805
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: 8bit

I've changed the title, because this thread now seems to be going in a different, and interesting, direction.

While I don't agree with the argument that says that a certificate should be revoked when the key was deliberately destroyed, the question of what to do if the key is merely "bent", i.e., made unusable to the user, but not completely unrecoverable, is an interesting one to consider. 

I can understand the point of view that says that a user who thinks that a key has been completely destroyed might be considerably less careful regarding the protection of the media containing the key than he might otherwise be. Dragging the key to the recycle bin might fall into that category, depending on how the operating system does object reuse.  (Note the interesting difference in connotation between a "recycle bin" and a "trash container".)

Even zeroizing keys in hardware isn't all that easy, depending on the sophistication of the attacker.  I suspect that NSA, Sandia, IBM, Intel, and MIT, to name a few organizations, have the necessary equipment to take apart even a FIPS 140-1 level 4 tamper-reacting device or chip and extract a supposedly zeroized key.  But I also suspect that the key would have to be awfully, awfully valuable to make it worth the effort.

But let's assume the currently popular practice of keeping keys on your hard disk, protected by a passphrase (assuming you used the high security option -- otherwise they're much less well protected).  What advice can we technical gurus give the relatively uninformed, naive user as to how they should go about destroying a key they no longer need?

One technique that I'm reasonably sure would work would be to keep the key on a floppy disk, and when they want to destroy it, first delete the key, then reformat the diskette, then run it through a tape demagnitizer, then shred it, then burn it to separate the iron oxide from the binder, and finally, disburse the ashes over a wide and inaccessible area, such as the middle of the Pacific ocean.

Now granted, that may be overkill for the kind of keys that are likely to be kept in software. And so far, I can't figure out how to tell IE 5.5 to store the working copy of  the key on a floppy disk in the first place.

So if you were the person responsible, what would you tell your users to do?

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software



>>> Marc Branchaud <marcnarc@rsasecurity.com> 06/11/01 11:03AM >>>

All I'm saying is that "destroyed" does not mean that the key can't be
recovered by someone with enough determination and expertise/money.

Yes, in theory, if a key is actually wiped from existence then the security
reasons for revoking its certificate are fairly weak (to be diplomatic about
it).  However, I seem to recall seeing reports a few months ago about some
data being recovered from a hard drive even though the data was overwritten
many times.  Destroying information seems to be a lot harder than expected.

Tony's original question concerned the accidental destruction of a key.  I
suggest that "accidental destruction" really means that the key is beyond the
owner's ability to recover it.  But that doesn't mean it's beyond everyone
else's ability as well.

For your average user, "destroyed" might mean that they accidentally dragged
their private key file into the trashcan.  This would hardly be "Destroyed"
in the theoretical sense, but if the policy is that there need be no
revocation when a key is "lost" then there's a huge vulnerability here.

		Marc


Santosh Chokhani wrote:
> 
> You could revoke, but there is no compelling security reason just because
> the key is destroyed regardless of the sensitivity of the subject component
> or the application.
> 
> Now, if some other foul play is suspected as part of the destruction event,
> that is another matter.
>