[117113] in Cypherpunks

home help back first fref pref prev next nref lref last post

Re: Project: Hardening Crypto Against Big Brother's

daemon@ATHENA.MIT.EDU (Sean Roach)
Thu Aug 26 17:11:07 1999

Message-Id: <3.0.6.32.19990826154128.007d76d0@mail.intplsrv.net>
Date: Thu, 26 Aug 1999 15:41:28 -0500
To: cypherpunks@algebra.com
From: Sean Roach <roach_s@mail.intplsrv.net>
In-Reply-To: <37C56CD3.80617638@brainlink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: Sean Roach <roach_s@mail.intplsrv.net>

At 12:35 PM 8/26/99 -0400, Sunder wrote:
>Here are the flaws/fixes:
>
>If I backdoor the big box, you login with your little box and start doing
>work.  I can now cache the plaintext somewhere where I can get to it.
>
>If you use the big box for disk access only (say as a file server) and use
the
>small box to do work, (the protocol doesn't allow any programs to run on your
>small box from the big box) then you must keep it with you at all times to
>prevent it from being backdoored.
>
>So now I'd have to somehow get my hands on your small box to bug it.
>
>There are several ways to do this.  
>
>Most importantly at some point you will sleep.  When you do (and your sleep
>may be chemically enhanced) I could get to your small box and add the back
>doors.  So you'd have to add some C4 to the small box to blow my fingers off
>if I touch it.  Barring sleep, you could be mugged, pick pocketed, etc...
>
>If I have tempest equipment I could get at your display and even figure out
>what your small box's CPU is doing.  So you'll also have to tempest proof
your
>machine somehow.  It's no longer such a small box. :)

This may become less of a problem if we ever go to optical chips/busses.

>If you do have some sort of trap that will blow my fingers off, then I could
>attempt several things: freeze it to near zero to disarm the trap, wait until
>the batteries run out, X-Ray it to find out where the trap is, etc.  You'll
>have to put sensors in to watch for temperature extremes, XRays and blow the
>C4 before the circuits that do that die, etc...  if the battery gets too low,
>fry all data on it, etc...
>
>This is the type of equipment you will need.  The small box is looking more
>and more like a low end portable computer.  I'd say Palm, but their CPUs
>aren't going to have enough horse power to do real time disk decryption.  I'm
>not quite pushing a mickeysoft product so don't get your panties in a bunch,
>but wince boxes are based on RISC cpu's, and may have flashable ROM's... If
>they do, you flash'em with your own OS, etc...  Better yet one of the
Libretto
>or small mini Sony Vaio's...
>
>You'll also have to keep this box off the net incase I do manage to install
>back doors.
>
>
>Keep the keys on a PC card encrypted with a passphrase, but typing it in
>shouldn't be the only thing.  Do all your work from this small machine.  (Of
>course CPU power will limit you a lot.)
>
>You'll also need some sort of dead man's switch that's easily accessible.  A
>few mercury switches well positioned could arm it, and if you don't type in
>the right passphrase in the right amount of time, it wipes the card, maybe
>beeps at you in a pattern (or better yet plays Yankee Doodle Dandy :^), to
let
>you know it's too late, and then blows itself to bits.

I don't see how the mercury switches would be a good thing if it is a
portable.  Better a combination on the case that will set off the failsafes
if the wrong combination is entered more than twice.  With a spare
combination which will apparently open it up but only allow access to dummy
files.

10^4 possible combinations wouldn't be too bad security if (10^4)-4 caused
a meltdown, 1 released dummy files and only 1 actually did what it was told.

>When you do use your key, it should wipe the card incase you don't get a
>chance to do so, or they manage to eject it.  When you tell it to shut down,
>it should write the key back, but with a new random salt.
>
>(There are also issues of key recovery if the hardware does go bad, or if
your
>pet cat/dog/lizard/ferret/rodent lands on it and sets off the deadman switch,
>but presumably, you wouldn't leave the machine lying around at all.  If
you do
>you open yourself up for a hardware bug being planted.  If you do put an XRay
>detector in it, be sure to disable it when you go through airports incase
they
>don't do hand inspections - but then C4 becomes an issue, etc...)

Better.  Use thermite.  Since its only almuminum powder and rust, it
shouldn't look like more than a large mass of metal, (of which the case has
a lot of anyway.)

Perhaps a proximity sensor trained on a token hidden by your surgeon.  Step
too far away and it becomes a worthless piece of junk.

Flash memory is no good for holding the OS.  If it can be updated through
software, you might have just opened youself back up to backdooring.
Better to use EEPROMS with the erase pin passed through a hardware switch
so that you actually have to manually flip it to update your OS.

If you are going to have the system maintain an encrypted filesystem
anyway, you might as well use a hardware solution to encrypt/decrypt.  Just
like using a video accelerator to free up the CPU for more important tasks,
have a crypto accelerator built in to your disk controller.  Someone
mentioned a chip that handles DES, stating that you could use several to
manage 3DES.  I suspect you would want a chip built around the most secure
algorythim in use.  Also, you wouldn't need to retain backward
compatibility on fixed disks, so you could keep that at least at the
cutting edge.

Also, if you can manage it, the non-executables that you swap around, like
text files, should be fully human-readable.  Something like HTML, but with
better control.  (Perhaps a coordinate system for placing of elements like
pictures of underlines.)  This way, you can visually inspect the word
processor documents without having to worry about if someone hid a command
in there.  This will, however, make your word processor documents much
larger for the same output.




home help back first fref pref prev next nref lref last post