Slashdot Mirror


On the (Im)possibility of Obfuscating Programs

sl956 writes: "We all know that anybody using the words 'tamper resistant' to describe a software-based solution is incompetent at best. But some of the big players in the DRM field are believing in software-only protection schemes (see Cloakware, Hitachi, IBM or Intel). A mostly unnoticed paper presented to CRYPTO'01 (Santa Barbara, CA, August 19-23, 2001, LNCS vol.2139) *proved* the impossibility of efficiently obfuscating programs. It is the mathematical proof of the impossibility of a software-only DRM system on an untrusted client such as a PC. There are also a lot of interesting theoretical side-effects. You can read the html abstract here, or the postcript full paper here." The paper is from last year, but that doesn't make its conclusion less interesting. (Of course, even hardware isn't always all that secure, either.)

9 of 215 comments (clear)

  1. Mozart by rjamestaylor · · Score: 5, Interesting
    In my Music Appreciation (Apprehension?) class I learned that as a young boy Mozart broke a vaulted DRM of his day by simply attending a concert in an Italian church. The mass that day was kept under lock and key and would only be played once a year; all copies of the music were kept secret. What Mozart did is hear the mass (once) and then went home and wrote the entire score as if he was copying the original documents yet only assisted by his memory. His scoring was so good he was accused of stealing the score from the church. (Forgive my poor recollection of Mozart's superb recollection ancedote...)

    There will always be a Mozart to break the DRM of publically performed (or distributed) works. DRM is a way of controlling the sharing of some piece of work. In reality, the only way to perfectly safeguard the rights is to not share the work -- or trust people. Hmmm...

    --
    -- @rjamestaylor on Ello
  2. Could this proof hamper the DMCA? by CptnKirk · · Score: 5, Interesting
    Now with this proof being published, software companies now have no expectation that their software only copy protection or DRM system is secure. What does this mean?

    If I wrote a copywrited piece and then used a form of copy protection that I knew people could break (similar to what some people were doing to "encrypt" song titles on Napster a while back), do I have the right to sue them under the DMCA (and a while back the judge said no)? Maybe so, maybe not, maybe it's a grey area, maybe there are other loopholes I know nothing about. But one thing I think the courts have upheld is that legally there is no degree of separation.

    For instance of a judge rules that breaking someone's "lame encryption" does not violate the DMCA, because they knew ahead of time that a person could break it. Then adding to the complexity shouldn't change anything. If you have a proof that shows that software only DRM on an untrusted client is not secure can you or should you be able to claim damages when someone eventually exploits the hole you knew had to exist.

    Of course IANAL, and I'm sure this will not cause the DMCA to crumble, but I think it raises some questions. Similarly are you allowed to advertise that such systems baised on obfuscation are secure or should they be clearly labeled as deterants, and not iron clad security?

    1. Re:Could this proof hamper the DMCA? by CptnKirk · · Score: 3, Interesting
      I agree with what you're saying. How about this though. Instead of a lock on your door, what if your home's security device was an elaborate maze. What if at the end of the maze there was no door. Now as far as I know you don't violate many laws if you walk into someone's house through an open door. The person selling you your maze security system tells you you're secure because only you know the way through the maze. Is this person liable when this security device fails? What if he knew ahead of time that his system offered no "real" security?

      Just food for thought.

  3. I've worked with Intel's DRM by KNicolson · · Score: 5, Interesting

    And they were always very careful to point out that their software is merely tamper *resistant*, not tamper *proof*. This is not just the sales guys, but the engineers too, and even in meetings if I accidentally said, for example, "*blah* will prevent copying", they were quick to correct my mistake.

  4. This isn't as big as the poster is making out.... by jpmorgan · · Score: 4, Interesting

    There's a paper called Protecting Mobile Agents against Malicious Hosts by Tomas Sander and Christian F. Tschudin, which demonstrates it's possible to write a program which can compute a digital signature or other various functions in such a way that it's impossible for the host to hijack the process, i.e., it's cryptographically hard to reverse engineer the program to extract the public key being used, or the function being computed (This paper has been used for various purposes, including proving that it's theoreticaly possible to write computer viruses which have signatures which are impossible to detect).

    These papers aren't contradictory, there are important differences between the results.

    Ultimately, one paper demonstrates a certain type or program (which would be usefull in implementing a DRM scheme) is impossible, the other paper demonstrates another similar type program (which would also be usefull in implementing DRM schemes) is possible (and demonstrates how to create such a program, and gives a non-trivial example).

    Is this the theoretical end of all DRM as the poster is suggesting? Not yet.

  5. Re:no, it's why the DMCA exists by CptnKirk · · Score: 3, Interesting
    You're quite right, and maybe the DMCA question isn't as debateable. How about the question of liability. Slashdot is currently discussing in another story the question of who is liable for buggy and insecure software. Take this example for instance.

    If it's decided that a company is responsible for it's security holes, can/should they be held liable for damages to a third party? For instance many labels are now using some form of DRM for their online services (PressPlay, MusicNet, Napster, etc). Since there isn't a lot of SDMI compliant hardware out there, these services are forced to use a software based DRM system on untrusted computers.

    Should BMG now be able to sue Microsoft for damages when someone figures out the obfuscation being used in Media Player 8? Is this akin to selling a service with a known unpatched security hole? I dunno, but I think it's an interesting question.

  6. dcc != practical by eddy · · Score: 3, Interesting

    dcc isn't practical though, unless you've got a heavily modified version. The offical version is hardwired to only support very small programs, and fixing that would require extensive rewriting of its internal structures.

    Not saying that it isn't interesting, only that today, no one (I'll wager) is using dcc for practical reverse-engineering.

    There's also rec (reverse-engineering compiler), but it's sort of limited in the kind of input it allows.

    IDA on the other hand is the tool of choice for the kind of reverse-engineering you're thinking of. If there were to be a source-generating backend on that one, you'd see a lot of worried faces, I assure you.

    --
    Belief is the currency of delusion.
  7. Re:software protection by CaptainSuperBoy · · Score: 5, Interesting

    Was that before or after you spent some time messing with trojans? Yeah you're not going to live that one down. Don't expect me to buy any of your software any time soon.

  8. Re:software protection by mpe · · Score: 3, Interesting

    if you use the hardware dongle for "proof of purchase" - just need to patch the check to the serial port :) but, a more reliable method would be to actually have program code *inside* the dongle that is downloaded at runtime to the memory space of the machine and is vital for the execution of the program :) that's a bit harder to "crack" - but, not impossible.. application needs more modification *g*

    Not that much more modification. All you'd need to do here would be to tack the code from the dongle onto the programme and have the downloading routine look at a certain memory address rather than a peripheral port...
    The only way of making this moderatly hard is to have the application run completly standalone, in other words in must contain it's own operating system, preferably on unmodifiable hardware, in which case you'd end up with something more like a games consome than a regualr computer.