Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Vista gonna destroy computers?

  • Subject: Re: Vista gonna destroy computers?
  • From: The Ghost In The Machine <ewill@xxxxxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 06 Oct 2006 03:00:05 GMT
  • Newsgroups: comp.os.linux.advocacy
  • Organization: EarthLink Inc. -- http://www.EarthLink.net
  • References: <xidVg.38887$Lb5.31162@edtnps89> <slrneiaulm.5bs.jason@jason.websterscafe.com> <lacgv3-tnh.ln1@sirius.tg00suus7038.net> <2027679.iNemiRRQsW@schestowitz.com>
  • User-agent: slrn/ (Linux)
  • Xref: news.mcc.ac.uk comp.os.linux.advocacy:1164781
In comp.os.linux.advocacy, Roy Schestowitz
on Fri, 06 Oct 2006 01:52:45 +0100
> __/ [ The Ghost In The Machine ] on Friday 06 October 2006 00:00 \__
>> In comp.os.linux.advocacy, Handover Phist
>> <jason@xxxxxxxxxxxxxxxxxxxxxx>
>>  wrote
>> on Thu, 05 Oct 2006 21:36:38 GMT
>> <slrneiaulm.5bs.jason@xxxxxxxxxxxxxxxxxxxxxx>:
>>> hym3n_h0l0c4$t@xxxxxxxxxxxxxxxxxxxxxxx :
>>>> Just saw a newsbite on the elevator telly claiming that Vista will be
>>>> doing permanent damage to non-licensed computers.
>>>> If even possible, I can't help but think this is a bad idea:   What
>>>> happens
>>>> for inadvertant copyright violators?    What about "false positives"?
>>>> I'm dying to see how this one pans out.
>>> That cant be right. Even MS knows they dont have rights to the hardware,
>>> just the software.
>> Why would they want such? :-)  Hardware is a lower-margin business.
> ...Wasn't there some issue with IBM over a decade ago? Rex happened to have
> mentioned damage at hardware-level, which by the way is possible. Whether
> it's a possibility /here/ I very much doubt it. The compensation/lawsuits
> over other hardware, e.g. XBox 360, were suffieciently damaging. They even
> encourages Microsoft to *gasp* merge a few divisions for financial purposes
> (reports), as means of hiding/mitigating the scale of failure and keep up
> appearances for that next press/investor's conference.
> Best wishes,
> Roy

It is certainly possible to design damagable hardware;
one such is a double fuse on an EEPROM-like device.
The first fuse is blown during registration, making the
device operational.  The second fuse is blown if something
goes wrong with the licensing, rendering the unit junk.

The EEPROM-like device would probably be wave-soldiered
onto a board as a SMT device, making removal by the average
person difficult, though not impossible.  (This is assuming
the fusible links aren't simply put into the microprocessor
itself, or one of the support chips.)

One could of course get arbitrarily sophisticated here; for
instance the EEPROM-like device might be blowable with
a random 4K-bit key.  I'm not sure where the bits would
come from, though, in that case.

A more elegant (and more robust) implementation would
allow for mask-programmed ROMs.  These ROMs, which would be
handed out like candy, would have the following facilities.

[1] It would allow for the readout of a public key, about
4k in length.  This public key would be guaranteed unique
by the manufacturing process, as would the private key, which
is hidden in the device (see below).

[2] Given an encrypted block, it would return the decrypted
block from the public or private key.  (The public key
encryption is mostly for convenience, as the server that
knows about this unit would already have the public key,
plus the algorithm used to encrypt, which would probably
be an RSA variant.)

[3] Given a decrypted block, it would return the encrypted
block from the public or private key.

[4] The device should be able to blow itself out given a
special signal, irrevocably losing the device, and ideally
the key as well, though with my knowledge of fab techniques
that may not be possible.

Since EEPROMS and EEAROMS have been around for awhile
this doesn't appear horribly difficult, though it might
be a bit tricky to do well, especially since one has to
guarantee no duplicate keys and no weak keys (like all
zeroes) during fabrication.  And of course such ROMs
could be part of an RFID, though there is some risk of
electrostatic discharge blowing out the device.  But then,
there's *always* some risk of ESD.

And of course there's the idea of selling this self-destructing
device to the OEMs, and to the general public.

Once the board starts to malfunction the intent would be
to send it in for servicing.  The servicing, of course,
would be the replacement of the ROM (plus all labor related
thereto), and the user would be on the hook to replace
all software which was dependent on the now-blown key.

Reverse engineering would be made difficult by fabricating
the mask on layer1 of metal, then covering it with a
thick lake of layer2 metal.  I'm not sure how to fill in
the gaps properly on layer1 of metal with glass oxide so
that layer2 metal remains flat, though -- and I'm not that
knowledgable about process engineering. :-)  No doubt
someone could have some brilliant ideas here.

The user would be required to provide his public key
(extracted from his machine, of course, or perhaps
supplied therewith on a small card or USB stick [*]) during
the purchasing process.  The CD would be burned and be
usable only by the private key matching that public key.
The unencrypted data would be guarded as closely as Fort
Knox, or perhaps would be encrypted by the seller's public
key, so that only the seller can decrypt it and reencrypt
it using the buyer's public key.

And remember, all this is for the user's protection against
those evil nasty counterfeiting pirates.  Can't be too
careful, you know. :-)

[*] the stick would not be a dongle; it would merely be
a convenient method by which to carry the public key.
Of course, it could be employed as such by software, which
could take the public key from the dongle, compare it to
the device's stated public key, then encrypt several random
test blocks using that key and have the device decrypt it,
and ensure everything's proper.

#191, ewill3@xxxxxxxxxxxxx -- insert random lead balloon here
/dev/brain: Permission denied

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index