1993-06-05 - Re: CryptoStacker, long term vision

Header Data

From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
To: RYAN Alan Porter <ryan@rtfm.mlb.fl.us>
Message Hash: f91e41fe9d30087f23fc6605fe671a1e7af91f92a7cd41792a6992562a5685da
Message ID: <Pine.3.05.9306051259.A17856-c100000@jupiter>
Reply To: <Pine.3.03.9306030013.A18959-e100000@rtfm>
UTC Datetime: 1993-06-05 15:37:18 UTC
Raw Date: Sat, 5 Jun 93 08:37:18 PDT

Raw message

From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
Date: Sat, 5 Jun 93 08:37:18 PDT
To: RYAN Alan Porter <ryan@rtfm.mlb.fl.us>
Subject: Re: CryptoStacker, long term vision
In-Reply-To: <Pine.3.03.9306030013.A18959-e100000@rtfm>
Message-ID: <Pine.3.05.9306051259.A17856-c100000@jupiter>
MIME-Version: 1.0
Content-Type: text/plain



> As for those people that can't afford to use dedicated hardware, there is
> still the less secure idea of having the key stored on a floppy that would
> be inserted at load time and read into memory.  This would have the
> obvious disadvantage of having the key sitting around in memory, a sitting
> duck (especially for people who leave their systems on all of the time,
> like me, as soon and the Nazis learned about systems like these then 'Run
> a key scanning program on the system to be confiscated' would just become
> step one in their procedure, would be a hole even if the keys were
> password protected) but it would be better than nothing at all, and the
> speed problems could be dealt with by using the multiple partition method
> that I described earlier, having a 'secure' virtual disk where all of your
> data goes, and a seperate 'fast' virtual disk which is unencrypted where
> all of your programs and such go.

Hmmm...  I have a suggestion to make keeping the key in memory a little
more safe, though I don't think there is way to prevent a properly
resourced person/agency/enemy from getting it (or any other data in the RAM of
the computer).

You first need a machine which has a supervisor state, which *only* the OS
can run in.  Your cryptostacker will be part of the OS and as such, user
processes cannot access its memory.  This way, the attacking agency will
have difficulty just running any old program to copy all of the CPU's
memory to a disk.  The only way to add new programs to the supervisor
state (OS) would be if the machine is power up in a special way (with a
certian boot disk for example) so that once the machine is running there
is *no* software method to read any OS data.

You would also want to avoid storing the crypto key at a fixed memory
location.  Allocate some memory at a variable location at each startup and
store this location *only* in a register.  This should make it even more
difficult to get the key, because you would need to be able to check the
supervisor stack to find the right register to find the location of the key.

This raises the question of just how much work an agency goes through when
it is first confiscating a machine to ensure that they can get at all the
machines data.  If the first thing they do is turn the machine off to be
able to pack it up, then you are all set.  (Assuming you didn't manage to
turn it off before you lost control of the machine.)

What kinds of things can you do to your home machine to make more tamper
proof?  If you have an "easy access" case, how about installing a micro
switch that will reset the machine (or power cycle the system) when its
opened.

---
Nick MacDonald               | NMD on IRC
i6t4@jupiter.sun.csd.unb.ca  | PGP 2.1 Public key available via finger







Thread