Date: 22 Dec 1998 19:07:10 +0100 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Dag-Erling Smorgrav <des@flood.ping.uio.no>, cjclark@home.com, Janos Mohacsi <mohacsi@bagira.iit.bme.hu>, security@FreeBSD.ORG Subject: Re: preventing single user login w/o password Message-ID: <xzpsoe8t5ip.fsf@flood.ping.uio.no> In-Reply-To: Robert Watson's message of "Tue, 22 Dec 1998 12:16:13 -0500 (EST)" References: <Pine.BSF.3.96.981222121213.15464C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <robert@cyrus.watson.org> writes: > On 21 Dec 1998, Dag-Erling Smorgrav wrote: > > "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> writes: > > > "There is no security without physical security." > > Well, you can translate physical access to the computer into physical > > access to a more manageable item, such as a Java ring, if you use some > > kind of hardware device which strongly encrypts your disks and keep > > the encryption key on the Java ring. The idea is that you can't boot > > the computer without the ring, and you can't decrypt the contents of > > the disk drive without it either (not within reasonable amounts of > > time, anyway). > I'm actually not sure this is a solution. If I have physical access to > the machine, I can induce (via hardware or software) a mechanism to > capture your key when or before you attach the key to the machine so that > the decryption can occur. We're making different assumptions. You're making the assumption that you can get access to my machine, install your snooper and get out undetected. I'm making the assumption that you can get access to my machine and try to reboot it into single-user mode (perhaps using a boot disk) but that afterwards, I know you've been there and will take appropriate measures (examine the hardware for traces of tampering, etc.) > I think there is a fairly strong evidence that > 'tamper-proof hardware' simply cannot exist, at least not economically, if > not at all. If your key was required to perform the disk-decryption > operations, presumably that is a step in the right direction, but if it > just transfers the key, I come in and set something up to intercept the > key when you arrive to boot the machine. Yes, I was envisaging a system where the floppy contains a short program which downloads the key to the cryptographic hardware, and proceeds to boot the OS. Obviously, if you can snoop the key you're in. But it would be trivial (in the sense of "it's been done before") to implement a challenge-response protocol which makes playback attacks impossible. You then have two keys: one which is used to encrypt and decrypt harddisk data, and one which is used for downloading the other key to the controller (or for negotiating a session key, or whatever). The controller has one half of the negotiation key stored in NVRAM and uses it to generate challenges; the iButton has the other half, which it uses to generate responses. When the controller and the iButton are satisfied that they are talking to the intended protagonist, the iButton transfers the encryption key, encrypted with the negotiation key or a one-time session key to the controller. I don't think this is particularly revolutionary stuff; in fact I wouldn't be surprised if there were already systems on the market that behave as I described. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpsoe8t5ip.fsf>