4

I've been wondering how iTunes movie rentals work from a security standpoint. Given that the "rented" files are actually downloaded to the user's computer and then played from there, it seems like there is no way to prevent the user from saving the files indefinitely.

It's possible that the files are stored in some proprietary format (something like CSS), but this could easily be subverted in the long term by reverse engineering the code that plays them (as happened with DeCSS).

I'd be very glad if someone could point me to some references analyzing this system.

1 Answer 1

2

DRM systems tend to all work according to a variation of the same basic principles:

  • Contents are encrypted with a symmetric cryptography algorithm, such as for example AES-128.
  • The content key, along with a machine-readable description of usage rights (such as "play for 48 hours") is delivered to the user's device upon content purchase.
  • This key+rights bundle is often called a "license", and is itself encrypted with public key cryptography. This implies that the user device possesses the private key to decrypt this license.
  • Upon content playback, there is necessarily a "trusted" piece of software running inside the playback app - in this example iTunes. "Trusted" is in quotes because Apple trusts it, not you!
  • This piece of software, sometimes called an "agent", is in charge of decryption and - importantly - enforcement of the usage rights. In this example, it will perhaps self-destroy the key after 48 hours.
  • Agents, due to their nature, usually come heavily armored against attacks, to defeat reverse engineering attempts: decompilation will yield garbage results, debugging is made impossible, etc.

So... To answer your question: yes, the content and the decryption key are both on the device (at least for a while) but there's a machinery working against any attempt to put them together. People have occasionally succeeded in the past, but the bar is getting higher all the time.

1
  • 1
    I doubt your last bullet point is strictly correct -- no matter what level of obfuscation is done, it is no doubt still possible to reverse engineer the code given enough time and effort. Also, while debugging "hints" are no doubt removed from the compiled code, debugging is by no means impossible under such conditions.
    – augurar
    Nov 23, 2015 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .