/. [Intel Adds DRM to New Chips]

[sunder]

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.)