[32779] in bugtraq
Re: Dell BIOS DoS
daemon@ATHENA.MIT.EDU (Eric Anderson)
Wed Dec 10 15:09:51 2003
In-Reply-To: <3FD62A57.1070005@tippett.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-372060738"
Message-Id: <4C548314-2AB3-11D8-A1EA-000A95A1508A@cs.uoregon.edu>
Content-Transfer-Encoding: 7bit
Cc: "'jon schatz'" <jon@divisionbyzero.com>,
David Brodbeck <DavidB@mail.interclean.com>, bugtraq@securityfocus.com
From: Eric Anderson <anderson@cs.uoregon.edu>
Date: Tue, 9 Dec 2003 17:50:57 -0800
To: Craig Paterson <craigp@tippett.com>
--Apple-Mail-1-372060738
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Dec 9, 2003, at 12:02 PM, Craig Paterson wrote:
> David Brodbeck wrote:
>
>> There is no such thing as security from someone who has physical
>> access to
>> the hardware.
>>
>
> Alright, so this is a tangent, but: that is what encryption is for.
> The whole basis of encryption assumes that the attacker has access to
> the message (your data), but that without the appropriate keys you
> can't usefully access it. No, this doesn't have much to do with the
> value or otherwise of BIOS passwords, but it's often stated that
> physical access renders all your data wide open, which isn't
> necessarily the case.
I'll continue the tangent: Encryption's great against an attacker who
has physical access to the device holding your data, as long as they
don't have physical access to the device holding your keys! We can
sort of separate hardware into:
Type 1. Storage/transit parts which only handle encrypted data and
never see the key.
Type 2. Use/processing parts which operate on the unencrypted data,
and thus need the key (or only deal with the plain text in the first
place.)
The maxim then becomes "There is no such as security from someone who
has physical access to the (type 2) hardware."
I would describe most of the "secure/trusted hardware" efforts that
I've seen (such as the system Alexandros Papadopoulos mentioned) as
trying to move as much of the system type 1 as possible, and make the
type 2 bits user-inaccessible. There are a few interesting things you
can do with data without decrypting it at all (a pure type 1
situation), but most applications require some type 2 bits. The trick
with a secure cryptographic coprocessor is that the exposed data bus
can be type 1, with the type 2 operations happening somewhere inside.
This would accomplish nothing against an attacker with absolute
physical access who could read or change the voltage anywhere in the
chip at any time. But it does work against an attacker with "normal"
physical access who can only observe or tamper with data on the chip's
external interfaces.
--
Eric Anderson - anderson@cs.uoregon.edu
University of Oregon Network Security Research Lab
PGP fingerprints:
D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12
9544 C724 CAF3 DC63 8CAB 5F30 68AE 5C63 B282 2D79
--Apple-Mail-1-372060738
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQE/1nwFdLdTpjx0XxIRAgOBAJ4xvS+ZNyKCp21PRhV6UZw/YNm6/ACZAayq
gAzOy4oEqlfcEswg7HNdtqE=
=8t48
-----END PGP SIGNATURE-----
--Apple-Mail-1-372060738--
