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.)
i have a mathematical proof that shows the impossibility of mathematical proofs, but i can't get it past the lameness filter.
as a developer myself, i spent a bit of time messing around with protection schemes for applications i wrote for the Palm OS platform. i wrote a paper on it, which was made available at PalmSource 2000 and is available here. i enjoyed understanding the inner workings of how they did it - so, i documented it. however, i knew that there was no beating them - the question remained.. how long would it take for them to crack it? does it give me some selling breathing space? (more time = more sales) :P
...because it means that the ONLY recourse for these money hungry bastards in the "content industry" (is legal prostitution considered and "industry"?) is legislation. As long as they can be fooled into thinking that Mr. Wizbang's new ROT-14 encryption scheme is uncrackable by all but the most devious of minds, they will relax and let themselves sink slowly into the mire of contentment that will someday be thier graves. But when people come around spouting off how impossible it is to have DRM on "untrusted" machines, the only solution is legislate trust into all the machines in the most draconian and Brotherly way possible.
PLEASE somone start publishing papers on how all digital content can be protected by XORing it with the number 0x42 and will be secure as such for decadeds to come.
"Your superior intellect is no match for our puny weapons!"
Although they formalized a counter-example to an already special case, which precludes generalization of the concept, that does not mean other specific cases do not apply.
Of course, mostly the DRM people are interested in making things sufficiently hard to do, not impossible.
They are driven by profit, not purity of outcome, so if a scheme costs more to run than it delivers, it will not be used.
Likewise, tweaking a DRM system to maximise returns involves evaluating the cost of the DRM system itself, and the hassle it gives to legitimate customeers. Just having a 100% success rate means nothing if you only have 2 customers left.
Michael
There is no cryptographic solution to the problem where the intended receiver and the attacker are the same entity.
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
It was already obvious that this was true.
Quick proof:
1)A software-only DRM system attempts to make a product run in cases where it is not a copy.
2)It makes it's decision based on information content of some kind.
3)A copy will perfectly replicate all information content. (If it can't, then you don't need DRM.)
4)If a copy has the same information content as the original, then the DRM cannot distinguish between the copy.
5)Therefore DRM has no way to shut down only the copies.
6)The only way to make DRM work is to have some sort of information that is impossible or very much harder to copy. Thus, the web-activation type scheme, although IP packets could easily be spoofed.
7)God, I should have published this years ago, if it weren't so GODDAMN OBVIOUS!
I read the article last year when it came out. The results are not as far reaching as they sound from a first reading of the abstract.
They proved that not every function is obfuscatable. However for all we know, it might be that most functions are obfuscatable, which is good enough. Also the notion of obfuscation is somewhat contrived (this is because of the lack of a generally well defined notion of what de-obfuscation is, they did the best given what is a new field).
Say, in general proving that a program terminates is impossible. Nevertheless millions of lines of code are put out every day which we are positive they terminate, as we restrict ourselves to designing programs that always do so (even though the occasional bug gets in the way).
I don't want to be a pedant, but resistant doesn't mean immune in all contexts, it also means "the attempt to prevent something by action or argument" [or something to that effect - I don't have a dictionary within reach].
So tamper resistant isn't an absolute statement and often refers to the ability to buy time. However many companies (typically the saled dept.) often refer to it as though it buys *complete* piece of mind, yet even physical bank safes are rated by time to resist cracking/breaking.
I think this paper is good because it means that PR claims can be provided with a counter argument from a third party that provides a proof. However I think that anyone using the word tamper resistant is not an imbecile, I think that anyone who uses it in the context of tamper-proof is an imbecile. Resistant has so many contexts.
e4 e5
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?
If a piece of software (with some kind of copy-protection) runs on a computer, it can be cracked to run without that protection. Tools such as Procdump will start the program, and after the user has clicked yes on a nag box and the program is decryptet, procdump will scan the memory and rebuild the executable.
If a movie or music file is protected by some encryption it still has to be decrypted to be played. There are many ways to crack this. Crack the encryption, intercept the data stream after it has been decrypted or just record the analog stream. A small quality loss, but with no protection at all. I remeber reading an article by Tron Øgrim, where he had interviewed a boss in a publishing corporation or something like that about DeCSS and ways to protect digital data (movies in this case). He asked if they had some way to stop people from just using a camcorder to record the tv, and the boss-guy said no, and I had the impression that they just hadn't thought of it. They can protect their movies and music with super-strong encryption, but people still have to be able to watch the movies or listen to the music. If people can watch or listen to it, they will be able to record it.
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.
All programs have to be "interpreted" by something when run. Usually it's a hardware CPU but it could just be a good software emulator. If a program is running on a s/w interpreter emulating a CPU it's trivial (though lengthy) to determine the algorithms and data used by the program. It doesn't matter how hidden the code and data are, when they hit the CPU they must make sense.
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.
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.
The first time a traveling salesman walks into my living room, I complain to my maze provider. He then releases Labyrinth 2.0. Instead of a maze of brick, the maze is now full of mirrors.
Of course this maze is foiled by crafty salesmen who lay breadcrumbs and place markings on the ground to indicate where they'd been (sure they could have done this before, but lets say they didn't).
So again I complain and the maze provider offers another solution. But this time the maze provider does something new. Labyrinth 3.0 offers support for trolls who live under the maze and can rearrange the markings and discard the breadcrumbs left by the salesmen. You can buy the trolls from the maze provider as well as troll food each month.
Now I've paid for 3 versions of my Labyrinth security product, and am continuing to pay now for trolls and food on a per month basis. My maze provider is now a huge corporation. Should they have to pay if their supposed security system fails?
What if they knew all along that the maze technology was insecure and that no matter the obfuscation there was always a way an intruder could enter your house through supposedly legal means (assume that simply using the maze fairly is not illegal). If it can be shown that the maze provider knew ahead of time that maze tech was inherently insecure and that while the upgrades seemed to fix security holes as they were discovered, that these types of holes would always be present and are indeed unfixable. Should a company be allowed to continue to "upgrade" their technology and make even more money, while they know their product will never be fit for this particular purpose?