[119085] in Cypherpunks
Re: [TCFS] tcfs and the su command
daemon@ATHENA.MIT.EDU (Mike Hsu)
Thu Oct 14 14:33:24 1999
Message-ID: <38062578.65177C6B@vpdisk.com>
Date: Thu, 14 Oct 1999 18:48:24 +0000
From: Mike Hsu <hmike@vpdisk.com>
MIME-Version: 1.0
To: Ryan Lackey <ryan@venona.com>
CC: tcfslist@edu-gw.dia.unisa.it, cypherpunks@algebra.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: Mike Hsu <hmike@vpdisk.com>
Ryan,
Your analysis is correct. In theory, one can not have 100% security if the
computing
device is under the control of others. In practice, a reasonably secured
computing
environment can be achieved by making it VERY difficult for the privileged
users
(and hackers) to break the security. In addition, like you have suggested,
using a notebook
computer with Virtual Private Disk or CFS, TCFS could allow users securely
store
data on remote servers as well as local disks.
--Mike
VPDisk.com, Inc.
Ryan Lackey wrote:
> [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
