1998-12-18 - Re: …..

Header Data

From: Anonymous <nobody@replay.com>
To: cypherpunks@Algebra.COM
Message Hash: 60f04688ddb87d5e227b07b0abc36d2468b682036d5960844328f9e9f9c44be5
Message ID: <199812180521.GAA19817@replay.com>
Reply To: N/A
UTC Datetime: 1998-12-18 05:54:33 UTC
Raw Date: Fri, 18 Dec 1998 13:54:33 +0800

Raw message

From: Anonymous <nobody@replay.com>
Date: Fri, 18 Dec 1998 13:54:33 +0800
To: cypherpunks@Algebra.COM
Subject: Re: .....
Message-ID: <199812180521.GAA19817@replay.com>
MIME-Version: 1.0
Content-Type: text/plain



> Intel plans to include security features in upcoming chipsets, including copy
> protection, certificate management, and -- get this -- random number
> generation. This will be implemented in firmware, and, given that it is
> supposed to perform copy protection functions, there is a significant
> possibility that the code would be inaccessible, maybe (heaven forbid) within a
> tamper-resistant shell.

To clarify exactly why this is a problem: although it obviously won't affect
the security of existing apps, it's likely that many newer apps will be
dependent on this possibly-secret firmware for security, and we all know the
evils of depending on a design not subject to intense public scrutiny. Worse
yet, it seems possible that a certificate-based system could be used to ensure
that neither non-Intel chips nor software fill-ins would be accepted by
applications using the firmware.

And, of course, except for what was mentioned in the TechWeb article itself,
this is all conjecture based almost entirely on Murphy's Law.





Thread