Slashdot Mirror

You started on the right path. Then you went completely off! Crackers will simply have to do that: make a VM that's compatible with BD+. None of this full dynamic analysis hogwash.
Thing of all the video game systems and arcade machines. The video games on them had protection schemes, yet, can't emulators play these games? Yes they can. This is no different.

Alo, king of the smart replies. Well met. First: emulator cartridges are a static target attacked by dynamic code. Bluray DVDs are a dynamic target attacked by static code (if the attack is publicly released). This means arms race. As long as there is a detectable implementation difference, the next generation of BD+ will exploit it. How many implementation differences are there? Hello, Halting Problem (hat tip to later poster). It's like asking how much 0h-day is in Windows. Anyone who knew would be a billionaire, but we can't know. Enter the arms race. Who will spend more money, Sony or the underground? As far as dynamic analysis being hogwash - um... you do know that the intel instruction set is published, but no one can provide a static analysis tool that will tell you what an x86 program does? Same thing with virtual instruction sets.. I grow concerned about the tone of your post.
Second:

Just putting the same source code through a randomizing [...] makes the challenge immensely harder.
Again, no, crackers don't care. Emulate the protection layer!

This implies a serious lack of understanding on your part. I am concerned. http://www.cloakware.com/

Yes, with client certs witch can be stolen: people have physical access to the hardware. No amount of silicon will change that. Even IBM's expensive crypto pci cards for bank machines have been successfully attacked. The costs required to even attain a fraction of their security (batteries, temperature and x-ray sensors, etc) would, in a retail unit, be well over what the market would be willing to bear.

People have had physical access to Verisign's shit for years. Their certs remain unbroken. Money talks. People have had physical access to SecureId tokens, MILLIONS of them for years. I go on to mention this later. They remain unbroken.
I do not claim BD+ can't be beat. I did my best to define how. If someone drops the dime on their certs I will laugh myself silly.

To be completely broken yes, but that is unnecessary. One just has to have broken everything released up to that point.

Oh, fuck. You didn't read my post. Now I feel like Bob Lee Swagger. I'm DONE with you, son. Here's my post again:

BD+ allows the entertainment companies to react instantly to breaks at timeline point X, recompiling their VM code in a response to software breaks, protecting all titles published from time X+.

Now you are refuting me by repeating me. Sorry, other repliers get my time now.

Reply:

A hack seems inevitable now. Thanks.

Don't you get it? This system doesn't have one key! It has a different key in every DVD, protected by a different program. You need to mimic the runtime environment it expects in order to make that program extract its key. The key extraction method will differ for every disc. The tests of the runtime environment will differ every time. Think that's easy? GOOGLE AARD.
Jesus.

Reply:

You do not do the Halting Problem justice. Few if any bright minds are trying to solve it, because it is unsolvable. Trying t

I've done some preliminary testing and here's basically what it does:

• Stores usernames and passwords for applications, databases, etc. in a centralized database - encrypted with AES.
• Central database managed via a web interface.
• An application makes a call (via API or script) to CSPM daemon running on local machine to obtain desired username/password to target database. For example, the payroll application might ask CSPM for username/password to "PayrollDB".
• Daemon gathers evidence about requesting application (local username, current application path, hash of application executable, machine-specific fingerprint, etc.) and sends to CSPM server which uses the data to determine if the requestor is legitimate.
• Daemon caches server responses so that future password requests are serviced by local cache.

My only concern is that Cloakware licenses CSPM per-application ID (the software is "free").

Cloakware also has some nice obfuscation technologies

Cloakware also has some nice obfuscation technologies

But I don't see any reason to justify my claims either.

All PSPACE-complete problems are decidable by a machine running algorithm that uses P space. This PDF states that the acceptance problem (equivalent to the halting problem) for linear bounded automata (which it calles "linear bounded deterministic Turing machines") is PSPACE-complete. Here's an algorithm that decides it.

I attended the 2002 IPAM Crypto conference at UCLA where Steven Rudich gave a presentation on this. There is an important point that, from reading the comments thus far, is not being appreciated.

The paper does not say that programs can't be obfuscated. What it does say, is that there can be no generalized "obfuscator" that you run your program through and voila you've got an obfuscated version. Hoever, program obfuscation is possible on a per program basis. Simply put, the more obfuscated a program is, the more difficult it might be for someone to reverse engineer it.

The folks at cloakware have done what's supposed to be a bang up job of embedding AES keys in an obfuscated client. What that means is that you can use powerful, yet easy to compute, block ciphers with symmetric keys for "public" key cryptography. The clients will have your key embedded in the program, but in theory they won't be able to recover it. As the paper proves, Cloakware has to do the obfuscation on a program by program basis. They can't have a generalized obfuscating machine because such a machine can't exist.

Now, while I firmly believe that perfect DRM is an impossible goal (assuming no SSSCA), good enough DRM is certainly conceivable. If CSS had been obfuscated, DeCSS might have come out much later than it did. Program obfuscation could easily be used by those want DRM. They'd have to be prepared to be in a digital arms race, but they could probably as least give those who want to crack DRM a run for their money.

All things considered, we'd be better off if content providers were willing to trust software DRM rather than forcing all non copy-compliant hardware out of existence.