1993-06-10 - CryptoStacker (Key storage)

Header Data

From: rclark@nyx.cs.du.edu (Robert W. F. Clark)
To: cypherpunks@toad.com
Message Hash: d9a1a9e5d022b0a6c247a7d93bae2af1c6c1efb82bc5ddb51be29e38058f644a
Message ID: <9306101147.AA20987@nyx.cs.du.edu>
Reply To: N/A
UTC Datetime: 1993-06-10 11:47:44 UTC
Raw Date: Thu, 10 Jun 93 04:47:44 PDT

Raw message

From: rclark@nyx.cs.du.edu (Robert W. F. Clark)
Date: Thu, 10 Jun 93 04:47:44 PDT
To: cypherpunks@toad.com
Subject: CryptoStacker (Key storage)
Message-ID: <9306101147.AA20987@nyx.cs.du.edu>
MIME-Version: 1.0
Content-Type: text/plain


mmidboe@uahcs2.cs.uah.edu (Matt Midboe) writes:

>What is the problem with just having a regular key file, and when
>the user boots up the computer it asks them a pass phrase to decrypt the key
>file? If they fail wipe the key and force the user to restore the key from a
>backup somewhere. 

The problem with this is that a hostile third party who has captured
a machine will first make a backup of all files on the system, including
the key.  It is very likely that the party will bypass the initial
bootup procedure in which the key is requested, since the hostile
party expects some sort of 'data bomb,' having been involved with
systems confiscation for quite some time.  While there are some
options available, such as disallowing bootups from floppy, these
are in the main cheap hacks not to be trusted for security.

In this case, when the system is booted and the key is requested,
even if the key is wiped, they simply restore it from backup and
try again.  They are likely to keep the system for several months,
so they will have time to conquer any 'toy-grade' security.

While it is not yet standard procedure to make a snapshot of the
system memory when confiscating systems, the increasing cleverness
of law enforcement and other bodies makes this seem likely in the
future.  

So you can't have the key on the disk, nor can you have it hanging
around in cleartext in memory except when encrypted data is accessed;
preferably, the key should be encrypted, and on some fragile (i. e.,
easily destroyable) media.  Any backups should be encrypted, and
not easily accessible; preferably with a trusted party and not in
the same building as the computer with encrypted information.
----
Robert W. F. Clark              "Be sand, not oil, in the
rclark@nyx.cs.du.edu             machinery of the world."  Gunter Eich





Thread