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.