This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
SMTP error from remote mailer after RCPT TO:<[EMAIL PROTECTED]>:
host continuity.labor.koeln.ccc.de [2001:6f8:12f3:1:200:f8ff:fe76:53f3]:
550 unknown user
------ This is a copy of the message, including all the headers. ------
Return-path: <[EMAIL PROTECTED]>
Received: from outlier.minder.net ([65.75.150.100])
by weltregierung.koeln.ccc.de with esmtp (Exim 4.50)
id 1DffUs-0004Nu-QV
for [EMAIL PROTECTED]; Tue, 07 Jun 2005 16:56:31 +0200
Received: from waste.minder.net (waste.minder.net [66.92.53.73])
by outlier.minder.net (8.13.1/8.13.1) with ESMTP id j56Lk9a1080372
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <[EMAIL PROTECTED]>; Mon, 6 Jun 2005 17:46:10 -0400 (EDT)
(envelope-from [EMAIL PROTECTED])
Received: from waste.minder.net (localhost [127.0.0.1])
by waste.minder.net (8.12.8p2/8.12.8) with ESMTP id j56Lk8bY011388
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <[EMAIL PROTECTED]>; Mon, 6 Jun 2005 17:46:09 -0400 (EDT)
(envelope-from [EMAIL PROTECTED])
Received: (from [EMAIL PROTECTED])
by waste.minder.net (8.12.8p2/8.12.8/Submit) id j56Lk3Ao011355
for [EMAIL PROTECTED]; Mon, 6 Jun 2005 17:46:03 -0400 (EDT)
Received: from outlier.minder.net (outlier [65.75.150.100])
by waste.minder.net (8.12.8p2/8.12.8) with ESMTP id j56LjmbY011323
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <cpunks@minder.net>; Mon, 6 Jun 2005 17:45:49 -0400 (EDT)
(envelope-from [EMAIL PROTECTED])
Received: from proton.jfet.org ([EMAIL PROTECTED] [69.60.117.34] (may be
forged))
by outlier.minder.net (8.13.1/8.13.1) with ESMTP id j56Ljgxm080359
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for <cpunks@minder.net>; Mon, 6 Jun 2005 17:45:43 -0400 (EDT)
(envelope-from [EMAIL PROTECTED])
Received: from proton.jfet.org ([EMAIL PROTECTED] [127.0.0.1])
by proton.jfet.org (8.13.4/8.13.4/Debian-1) with ESMTP id j56Ljfe8010597
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <cpunks@minder.net>; Mon, 6 Jun 2005 17:45:41 -0400
Received: (from [EMAIL PROTECTED])
by proton.jfet.org (8.13.4/8.13.4/Submit) id j56LjbmO010574
for cpunks@minder.net; Mon, 6 Jun 2005 17:45:37 -0400
Received: from silkworth.sunder.net (node-423a1096.lga.onnet.us.uu.net
[66.58.16.150])
by proton.jfet.org (8.13.4/8.13.4/Debian-1) with ESMTP id j56LjQan010570
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <[EMAIL PROTECTED]>; Mon, 6 Jun 2005 17:45:36 -0400
Received: from [127.0.0.1] (silkworth.sunder.net [66.58.16.150])
by silkworth.sunder.net (8.12.11/8.12.9) with ESMTP id j56Lailc008032;
Mon, 6 Jun 2005 17:36:44 -0400 (EDT)
Message-ID: <[EMAIL PROTECTED]>
Date: Mon, 06 Jun 2005 17:46:05 -0400
From: sunder <[EMAIL PROTECTED]>
Organization: Sunder.NET
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: DiSToAGe <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Old-Subject: Re: /. [Intel Adds DRM to New Chips]
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6
(outlier.minder.net [65.75.150.100]); Mon, 06 Jun 2005 17:46:11 -0400 (EDT)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6
(waste.minder.net [127.0.0.1]); Mon, 06 Jun 2005 17:46:09 -0400 (EDT)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6
(waste.minder.net [66.92.53.73]); Mon, 06 Jun 2005 17:45:55 -0400 (EDT)
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by
milter-greylist-1.6 (outlier.minder.net [65.75.150.100]); Mon, 06 Jun 2005
17:45:43 -0400 (EDT)
X-SA-Exim-Connect-IP: 65.75.150.100
X-SA-Exim-Mail-From: [EMAIL PROTECTED]
Subject: Re: /. [Intel Adds DRM to New Chips]
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on
weltregierung.koeln.ccc.de
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=FORGED_RCVD_HELO,
SPF_HELO_PASS autolearn=ham version=3.0.3
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on weltregierung.koeln.ccc.de)
DiSToAGe wrote:
>not a backdoor, we forget to much that every system is only 1 and 0
>through electricity and physical circuits. If you can make them you can
>watch them (with time and monney i agree). Perhaps thinking that datas
>(certs, instructions) can be "hidden" behind a physical thing is only a
>dream ? I ask myself if not every cryptosystem where you must have
>something "hidden" or "physically not accessible" in point of the
>process is not sure ?
>
>
>
In theory the above is absolutely correct. In practice, it's extremely
difficult to properly implement an accurate enough emulator, however as
an emulator writer you have far more advantages than disadvantages
despite the 10-100x in slowdown. (Speaking from personal experience -
no, nothing on the kind of scale we're talking about here.) You can
always have your virtual CPU decide that when it sees a certain
instruction, to disobey it. For example, when it sees a checksum check,
to decide to jump around it and so forth.
Gotta love it when you can fool a program into thinking that 2+2=5 and
that everything is still A-OK with that! ;-)
If you can interface with real (protected) hardware, you might even be
able to get around public key schemes with the emulator. HP/Agilent
made some wonderful logic analyzers, which are very useful against
ancient hardware (think Motorola 68K chips at around 5MHz) too bad
nothing in the GHz range is (cheaply?) available out there, but there's
lots that can be done.
What can be done? For example, if you have something like Palladium or
whatever it's called these days, you an always build a machine that has
custom RAM that can change at the flip of a switch - sort of like the
old EEPROM emulators, but with RAM chips that can be flipped to a ROM
instead. You flip a switch after the DRM core has validated your BIOS
and operating system, and at some point once the CPU cache gets drained,
it winds up running code that it did not boot, code which you've written
to do *OTHER* things for example - simply change the IRQ vectors to
point to your code and you've taken over... Mind you, all this is
easier said that done, but it is possible to implement.
Remember, security is a chain, and each (media?) player out there is a
link in that chain. It only takes one broken player to wipe out your
entire investment in that DRM pipe dream.
Any employee with access can leak the master keys and the game is over.
Any wily hardware hacker with plenty of time on his hands can take a
shot at reverse engineering any (media) player to the point of cracking
it, etc. In the end, it's a waste of time and money for the makers of
DRM as there's enough interest that someone somewhere will break it at
some point in the near future.
You can play cat and mouse games by watermarking the output with the
serial # of the player in order to lock out cracked players, but the
attacker only has to break more than one player (perhaps two different
models so they get both serial # and model #) and compare the resulting
outputs from the same movie to figure out which bits contain the
watermarks. XOR is very nice for figuring this out. :-)
None of this worries me, because I don't give a rats ass about copying
movies or what not. Couldn't care less about it. I'll wait for the
shit to make it to HBO, it's usually not worth watching the waste of
Hollywood plotless overhyped crud anyway, so why worry about copying
it? The few titles that are worth watching, are also well worth buying,
and after a few months they can be had for under $20, so why bother?
What is cause for worry is that it's quite _possible_ for Intel or other
chip manufacturers to insert backdoors in their hardware which someone
will go through the trouble of discovering, which does put everyone at
risk. No matter how good your operating system and firewall rules, if
your network card (and drivers) decide to bend over upon receiving a
specially crafted packet, you're owned just the same.
Mind you, I've never run across anything close to this, except perhaps
the old F00FC7C8 bug in the original pentium (which really was a DOS,
not a back door) and the old UltraSparc I in 64 bit mode multiuser
hole. The Pentium IV hyperthreading bug is something recent to worry
about along the same line of thought.
Sadly, you haven't got much choice in this matter, you have to assume
that you can trust the hardware that you run on (unless you're willing
to make your own and have the resources to do so, etc.)
