Each time a new digital rights management (DRM) system is released, hackers are not far behind in cracking it. Reverse engineers have taken down the security protecting content encoded for Windows Media, iTunes, DVDs, and HD-DVDs.
SecurityFocus contributor Federico Biancuzzi tracked down Nate Lawson, the co-designer of the Blu-ray content protection system, and discusses the challenges of defending digital content, including the basic principles and mistakes of the design process, how much the hardware can help, the link between software protection and software security, and the role of security through obscurity.
SecurityFocus: Could you introduce yourself?
Nate Lawson: I'm most recently known for co-designing the Blu-ray content protection system (aka BD+) while at Cryptography Research. I now run my own security firm, Root Labs, focusing on reviewing and designing security for embedded devices and the kernel/driver environment. I got my start in network security as the original author of IBM/ISS RealSecure, a network intrusion detection system.
How did you start working on DRM systems?
I learned to program on Commodore computers. The C64 was where I saw DRM first appear, in the form of floppy disk copy protection. Being interested in codes and how things work, I was amazed that someone could put something on a disk that could be read but not written to another disk. Of course, we all know now that bits are bits and that once the protection is cracked, they can be written to another disk. I think even today, it's valuable to look at old copy protection to understand what makes a good or bad scheme.
To be a good DRM reverser, you have to make "leaps" of judgement about how the system behaves. It's all about saving yourself time that otherwise would be wasted looking at the wrong area. Also, you need a wide toolset to work around roadblocks the designer put up to stop the most common tools. For example, most anti-debugging tricks only stop things that behave like a debugger. If you build a custom tool that works on different principles (or at a different layer), it will be invisible to such techniques.
To be a good DRM designer, you have to cover all the bases. You need to weave encryption, checksums, timing, anti-debugging, and obfuscation with the main program functionality. It must be so integrated that the main program will become useless due to missing large parts of necessary code, even if someone can identify and remove all the protection.
Would you like to present us a few of the basic design mistakes and alternative techniques to avoid them?
I've seen a lot of bad designs, for example, a "warden" thread that sits and checksums the main program. Often, the main program just checks a timer that the warden updates to be sure it's alive. So the two pieces are not well-integrated as it's easy to trick the main program into thinking the watcher thread is running even when it's not (i.e., by poking the counter).
A better design would be to have the main thread hashing the warden thread and vice versa. Each checksum result is combined after a certain number of steps and if incorrect, sends the application down the path toward stopping. This means that both sides need to continue the full computation for the program to work properly, and that computation is not a simple counter or something easily cut out of either thread.
It's mostly a case of using a mesh paradigm versus a chain. A mesh is not just defense-in-depth. Instead of layering up the defenses, you have mutual dependence (say, both backwards and forwards) between layers and you have other stacks of layers with cross-dependencies.
Common mistakes are to implement crypto poorly or use easily-bypassed if/then statements. I write a lot about software protection on my blog, so see it for more examples about specific successes or failures of DRM.