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.

Is there anything we might copy from the design process of DRM systems to improve security in other systems or sectors?

Definitely, yes. One of the claims I made at my RSA 2008 talk was that software protection is beginning to spread into new areas. For example, obfuscation techniques should be added to disk encryption products like FileVault to hide the key in memory. This would help mitigate but not completely prevent attacks that involve rebooting your laptop and scanning memory for the key (see the recent paper: Lest We Remember: Cold Boot Attacks on Encryption Keys).

Adding a logic based on hashes of variables' value and stuff returned by functions instead of a classic if/else tree might prevent some active exploiting. Did you ever consider this aspect in your code?

You can think of anti-exploitation measures as a form of software protection. They use the same approach. ASLR (address randomization) is a form of obfuscation. From one run to the next, the attacker can't predict the addresses needed to exploit a program. Stack cookies are a form of integrity protection, where you checksum a region of memory to make sure it hasn't changed. All these measures were first introduced as part of software protection and are being extended to harden systems against exploitation.

It sounds as security through obscurity has some admirers among the DRM designers. What is the role of "secrets" in a DRM system?

In software protection, obscurity is everything. You're ultimately depending on the attacker to not be able to just "see" the key or how the protection works. That sounds weak and against normal security principles but actually works quite well in practice, if you're good at it.

Is there any feature you would like to see included in x86 and x86-64 CPUs that you saw in other architectures (I guess mostly embedded ones)?

Most virtualization escape bugs will be targeting the hypervisor itself. A few may take advantage of hardware bugs but those will be quite rare. I expect that side-channel attacks will continue to get more attention since there is now so much micro-architectural state that is being inadvertently exposed to code with different privileges running on the same CPU.

Intel AVX (SSE4) recently added some AES instructions to try to avoid timing attacks. It is incompatible with the AES instruction the VIA C5 first added back in 2003. Both help prevent timing attacks.They could easily add a flag that says "use a unique hard-coded key", which would be useful for encrypting data that can only be decrypted on the same box.

What is your opinion on the trusted computing architecture, and the Trusted Platform Module (TPM) in particular?

I don't envy the designers of trusted computing. They had a number of conflicting constraints. It had to be fully backwards-compatible with ordinary PCs. It was going to be mainly for DRM (see Microsoft's 2002 Palladium announcement), then it got changed due to the uproar to be primarily about detecting rootkits being loaded. It was not allowed to support symmetric encryption (i.e. AES) due to some non-US government complaints.

Anyway, trusted computing has a lot of barriers to overcome and I've yet to see a "killer app" for it. We'll have to wait.

What differences are there in the design process of a DRM system for a defined hardware-plus-software product (e.g., a console or media player), and that for a variable system such as Windows running on various hardware (such as, AMD, Intel or VIA)?

That's a huge fork in the road that is encountered very early on. Can you have custom hardware? How much can it cost? Even a small peripheral like a smart card can make the game more interesting.

If you're working with only software protection as in a PC, your best bet is to require some form of online access. This gives you a way to do updates. Since nearly all PCs have at least intermittent Internet access, this is a fair requirement today. However, the PC is also the toughest environment since there are so many reversing tools and skilled people focused on it.

Also, the rules of the game are changing recently with Microsoft Vista kernel patch protection. If you're a rootkit author, you just bypass it. If you're a software protection designer, you have to play by its rules. For the first time in the PC's history, it's not a level playing field any more. Virus scanner authors were the first to complain about this, and it will be interesting to see how this fundamental change affects the balance of power in the future.

Custom hardware often gives you a longer period until the first break since it requires attackers time and effort to get up to speed on it. However, it often fails more permanently once cracked since the designers put all their faith in the hardware protection.

One subject that sounds particularly sensible is the way you manage renewability. You can upgrade devices if they are connected to the internet, but what form of checks can you deploy on offline systems?

To renew security, you need some kind of update channel. For PCs, most vendors are just assuming some form of Internet access. That seems OK nowadays but they still need to be prepared to send out a CD if a few customers don't have it.

Satellite TV systems have long supported code updates sent over the air. These so-called ECMs target patches hackers have loaded onto their smart cards to get free TV.

With Blu-ray, we took the approach of using the disc itself. It has to be present at some point and has lots of storage (50 GB!), so it was a natural channel. When media servers are supported in the future, the code can allow the video to be moved off the disc, as long as it is copied also and some kind of authorization is received. As long as new movies keep coming out, new security code can be included to address known and potential attacks. This keeps you from reaching a "game over" scenario.

What will AACS (Advanced Access Content System) do next? Will it succeed?

At the moment, they appear to be in a lot of trouble. While they do periodically update player keys, the time between updates is much too long (6 months) and software players get hacked again too quickly. The deck is stacked against them for speeding up the update process since it requires them to identify a hack, notify the vendor, wait for the vendor to issue a patch and roll it out, then later release discs that revoke the old keys. On the latter, it's very difficult to hide keys in a PC software player and attackers can target the weakest one. Given that several updates have been hacked before the new discs were released, it seems they aren't going to win this battle.

They do have two tools they haven't deployed yet. The first is called sequence keys. This allows a disc author to segment the video and encrypt slight variants of each scene, encrypted under different keys. This would allow them to rip a disc using a particular tool (or find the video on P2P) and identify which model of player was used by which variants appeared in the output. However, I think it's unlikely this will ever be used since it complicates authoring significantly and only helps in identifying the player keys to revoke. This is only the first phase of the long process I described above and won't speed up the other steps.

The other is to go after the online server itself. Currently, only Slysoft has hacked AACS, and they are hiding the player keys they are using by putting them on a server. Other ripping software authors were copying those keys from them, so they decided to stop providing them in the app itself. This also makes it harder for AACS to identify which player keys need to be revoked. AACS could make up fake MKBs (key blocks) and send them to the Slysoft server. Depending on the decryption result, they could zero in on which keys Slysoft has. It's sort of like the game of Mastermind, where I tell you what parts of your guess are right. The downside is this also only targets the identification phase, it doesn't speed up other steps of their update process.

It will be interesting if they come up with something else. As things stand, it looks like AACS is becoming irrelevant if they don't come up with fundamental changes to their update process.

A lot of millions have been paid by media companies to develop DRM systems, but generally it's just a matter of time before they get bypassed. I am wondering if you think that this happens because these systems were not well designed, or we can't really design an unbreakable DRM system?

It's a matter of incentive. People who make players have the opposite incentive -- do as little as possible since free content sells more players. To put it more generously, they don't get any of the revenue from a studio that sells more copies if there is less piracy, and they usually have to bear all the cost of adding protection. Why should they care?

When we designed BD+, our goal was to let studios spend the money developing the security on a per-disc basis. All the player manufacturers had to do was provide a simple, compatible VM environment. That way if a studio cares more about protecting a particular title, they can put more effort behind its software protection. They are in the best position to measure if the DRM impacts their sales and decide how much to spend on it in the future.

That's the exciting thing for me about BD+. It's really the first time these principles have been brought into play in the mass market. It's an opportunity to prove if common memes about DRM are true or not. How much more money does a title make if it's not available on pirate networks for a few months after release? That's a question you can't ask with DVD since there is no example to use.

This year should be very interesting.