Clocks are the secret hole in DRM

Lawmeme's roundup of the Boalt DRM conference is terrific, and contains this very nice nugget:

The cryptographic handshake is more than just comparing two policies to make sure they’re identical. And, of course, if the content owner has built in an escape hatch to allow key revocation for security lapses, I’d better have some kind of strong assurance that they won’t decide to hold my music collection for ransom five years down the line.

But it gets worse. If that song is copyrighted – which, after all, is the putative basis for this whole game – that copyright will expire at some point. That means you need to build an expiration date into the rights grant (just in case your handheld is still around in 2098). Once you’ve done that, well, the device needs to be secure against rolling its clock forward to 2099; if it gets a time from a central server, that server had better be secure and trusted both by content owners and consumers.

Which demonstrates the wisdom of this:

Ed Felten also observed, in a different context, that much of computer science involves using bulldozers to shove tough problems into someone else's back yard.

The infrastructure for workable DRM doesn't just involve redesigning all hardware, outlawing open source, suppressing the speech of scientists and researchers, constraining fair use and first sale: it also involves creating a secure, authenticated timekeeping mechanism.

Link

Discuss

(via Joho the blog)