Recently it was revealed that Apple’s new DRM-free iTunes tracks come with the buyer’s name encoded in their headers. Randy Picker suggested that this might be designed to deter copying – if you redistribute a file you bought, your name would be all over it. It would be easy for Apple, or a copyright owner, to identify the culprit. Or so the theory goes.
Fred von Lohmann responded, suggesting that Apple should have encrypted the information, to protect privacy while still allowing Apple to identify the original buyer if necessary. Randy responded that there was a benefit to letting third parties do enforcement.
More interesting than the lack of encryption is the apparent lack of integrity checks on the data. This makes it pretty easy to change the name in a file. Fred predicts that somebody will make a tool for changing the name to “Steve Jobs†or something. Worse yet, it would be easy to change the data in a file to frame an innocent person – which makes the name information pretty much useless for enforcement.
If you’re not a crypto person, you may not realize that there are different tools for keeping information secret than for detecting tampering – in the lingo, different tools for ensuring confidentiality than for ensuring integrity.
[UPDATE (June 7): I originally wrote that Apple had apparently not put integrity checks in the files. That now appears to be wrong, so I have rewritten this post a bit.]
Apple apparently used crypto to protect the integrity of the data. Done right, this would let Apple detect whether the name information in a file was accurate. (You might worry that somebody could transplant the name header from one file to another, but proper crypto will detect that.) Whether to use this kind of integrity check is a separate question from whether to encrypt the information – you can do either, or both, or neither.
From a security standpoint, the best way to do guarantee integrity in this case is to digitally sign the name data, using a key known only to Apple. There’s a separate key used for verifying that the data hasn’t been modified. Apple could choose to publish this verification key if they wanted to let third parties verify the name information in files.
But there’s another problem – and a pretty big one. All a digital signature can do is verify that a file is the same one that was sold to a particular customer. If a file is swiped from a customer’s machine and then distributed, you’ll know where the file came from but you won’t know who is at fault. This scenario is very plausible, given that as many as 10% of the machines on the Net contain bot software that could easily be directed to swipe iTunes files.
Which brings us to the usual problem with systems that try to label files and punish people whose labels appear on infringing files. If these people are punished severely, the result will be unfair and no prudent person will buy and keep the labeled files. If punishments are mild, then users might be willing to distribute their own files and claim innocence if they’re caught. It’s unlikely that we could reliably tell the difference between a scofflaw user and one victimized by malware, so there seems to be no escape from this problem.