[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: awareness + flexibility + security

From: Michal Suchanek
Subject: Re: awareness + flexibility + security
Date: Sat, 12 Nov 2005 17:04:25 +0100

On 11/10/05, Bas Wijnen <address@hidden> wrote:
> On Thu, Nov 10, 2005 at 11:59:20AM -0500, Jonathan S. Shapiro wrote:
> > On Thu, 2005-11-10 at 16:40 +0100, Bas Wijnen wrote:
> > > At least me and Antrik have used [the GNU Freedom Principles] to
> > > reject supporting the TC chips.
> >
> > Nonsense. You and Antrik have made an argument of the form:
> >
> >   A particular feature has one harmful use, so we should remove the
> >   feature without regard to its benefits.
> Ok, perhaps it wasn't clear.  I wasn't trying to say it had one harmful use.
> I was trying to say it had only harmful uses.
> What does this chip do?  It allows people to check that a remote computer is
> running unchanged code.  In other words, it allows people to restrict changing
> of code ("if you change your code, you cannot use my service").  I do not see
> any other use of the chip.
> Now in a case like ATM machines, this may be acceptable.  But it isn't
> acceptable for GNU.  The whole reason GNU was started was to prevent this and
> to allow people to change the code they use.
As I understand it, a TC chip is a cryptographic device. By itself it
has these functions:
1) generate and store keys (securely so that they are not disclosed)
2) perform cryptographic operations (encryption, decryption and
signing with the private key, and possibly something else)
3) optionally (can be turned off) carry an "id" that could be used to
distinguish a particular chip from any other and/or to verify that the
chip is a particular model made by particular manufacturer (and since
the identification is based on asymmetric keys it is much stronger
than id based on reading a plain register)
4) software "attestation"

That attestaion function is not really that strong. There are a few
registers for hashes, and these have to be actively filled by some
So in case of GNU/Linux, the BIOS  would store its own checksum, the
checksums of  option roms (if any), the checksum of the bootsector,
and load it. Grub then would store its
checksum, checksums of the stages it loads, the kernel, the initrd, and load it.
You can later read these checksums. But what do they prove?
If you modify your grub, it can store anything it likes. The BIOS
cannot know because for the bios the loader is in the bootsector(mbr).
You can replace the bios with linuxbios, too (although this is a bit
impractical). And finally, the modules you load after you mount the
root filesystem are unknown to the grub, specific to the system (as is
initrd even if you used a precompiled kernel), and there are so many
of them they are unlikely to fit into the few registers provided.
So in the end it certifies nothing for me, and would not certify
anything for anybody else.
Even for Windows users, there  are uncounted versions of ntoskrnl, and
that is only one of the  numerous modules that constitute the Windows

In my view the TC chip can be used (or abused) like any other device
(such as network interface card). It has some useful functions (like
the secure key storage - but the keys are lost if chip breaks or is
reset), and some less useful functions (like the "attestation").
The "id" or "endorsement" function could be possibly used to reject
known broken chips (and it can be used  by Apple to refuse running OS
X on non-Apple hardware).

The whole functionality can be (as far as I can tell) emulated in
software, except the keys can be extracted from software, and the 
"id" or "endorsement" key will be yours, not one of a known



             Support the freedom of music!
Maybe it's a weird genre  ..  but weird is *not* illegal.
Maybe next time they will send a special forces commando
to your picnic .. because they think you are weird.
 www.music-versus-guns.org  http://en.policejnistat.cz

reply via email to

[Prev in Thread] Current Thread [Next in Thread]