[119074] in Cypherpunks

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

Re: [TCFS] tcfs and the su command

daemon@ATHENA.MIT.EDU (Ryan Lackey)
Thu Oct 14 08:51:53 1999

Date: Thu, 14 Oct 1999 05:36:11 -0700
From: Ryan Lackey <ryan@venona.com>
To: tcfslist@edu-gw.dia.unisa.it
Cc: hmike@vpdisk.com, cypherpunks@algebra.com
Message-ID: <19991014053611.B11185@leopard.venona.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <3804CE40.ED884B46@vpdisk.com>
Reply-To: Ryan Lackey <ryan@venona.com>

[from a discussion of whether TCFS could protect a user from a malicious
superuser on the same system]

Quoting Mike Hsu <hmike@vpdisk.com>:

> Try Virtual Private Disk from http://www.vpdisk.com, free downloads are
> available.
> In Virtual Private Disk, super user or 'su user' is not
> able to see the user's encrypted files.

Aside from marketing-land, it is impossible to protect a user from revealing
red data to an attacker who has full control of the user's trusted
computing base.

I have not extensively analyzed vpdisk - it looks like it might actually
be a useful product, and if it is simpler to use than cfs or tcfs, then
it's probably quite useful.

However, any claim that simply by doing the decryption on the fly on
the untrusted machine, rather than in batchmode or file-at-a-time mode,
the user is protected from a malicious superuser who can potentially
control every aspect of the user's execution environment, is demonstrably
false.

Imagine, if you will, a vmware x86 emulator.  On this emulator, running
on a massively powerful machine, emulate a lowly 386/16.  On this 
"virtual 386", run linux 2.2.12 and vpdisk.

The user logs into the 386.  It is impossible for the user to tell that
this is in fact an emulated system running on a more powerful system by
using commands on the emulated 386.  Potentially, a sufficiently intelligent
adversary could fully emulate the 386 on the powerful machine, even down
to generating virtual hardware interrupts, etc.

Every character the user types can be recovered by the superuser.  Even if
using a special one-time-magic-adaptive-encryption-algorithm which can
only be recovered by knowing the full state of the computer at time t,
user inputs which depend on unique challenges, etc., etc., and the
strongest symmetric encryption known to man, any file the user decrypts
on the virtual 386, even if only 1 bit at a time, is known to the attacker.
If the key exists anywhere on the virtual machine, even if it is only
accessed by the kernel on behalf of the user, a user with the ability to
watch the state of the processor at all times can recover it.

Rather than just running a kernel on a simulator, the superuser can just
hack the execution environment more directly -- running ttysnoop on ttys
or xterms to grab passphrases, transparently, and modifying ps so it does
not show these processes, or perhaps just sniffing kernel memory to 
recover the key.

While vpd may provide more safety from a casual superuser browsing user
files by accident, it wouldn't stand up any longer than tcfs vs. a 
malicious superuser who actually wanted to read the user's files.  For this
threat model, the only solution is for every user to have a true
trusted computing base consisting of user I/O, all CPU used on red data,
and a communications interface to the world where black data is stored or
exchanged.  A laptop running in system high mode, dedicated to a user,
running whatever encrypted disk package locally, storing the encrypted files
on network-mounted volumes on untrusted machines, fits the bill quite well,
running vpdisk, tcfs, cfs, PGP, or any other worthwhile encryption package.
-- 
ryan@venona.com
http://www.venona.com/rdl/
1024D/4096g 0xD2E0301F B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F


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