Over on Slashdot, contributor BlueParrot brings up a good concern with the type of watermarking I advocated earlier this year in Watermark Me! – that the seller can frame the buyer by releasing assets with the buyer’s details on it, for instance onto a P2P network and then filing a lawsuit. This is too much power in the seller’s hands.
Now, with the caveat that my copy of Applied Cryptography is back at the office, I’ll try to propose a protocol that will solve this particular problem with some simple public/private-key cryptography. It goes like this:
The buyer and the seller each have a keypair. They could be RSA, DSA, PGP, x.509, etc. The application which purchases the asset (e.g. a song) from the seller, on behalf of the buyer, would probably need to generate the keypair. This isn’t too hard. So, with that baseline in place, during a purchase:
- The seller encrypts a random secret to the buyer.
- The buyer decrypts this secret.
- The buyer encrypts this secret, and signs it, sending the encrypted block (with signature) back to the seller.
- The seller verifies the secret and includes the entire data block received in the last message (still encrypted and signed) in the data it embeds during watermarking.
To protect the buyer, the seller cannot now just put a song out on a P2P net with the buyer’s watermark data because he can’t fake the signed message back from the buyer.
To protect the seller requires a further step – proof of ownership of the keypair by the buyer. That is, should the buyer actually go and upload to a P2P network, the seller will want to have recourse, and he needs to know who released the asset. The seller, so far, only really knows the key ID# that participated in the transaction, not who the owner of that keypair is. There are many ways to tackle this problem, none perfect and easy, but I’ll suggest this addition to the protocol to make it attractive to both the buyer and seller:
- The asset purchase includes the transmittal of credit card data from the buyer to the seller encrypted with the same keypair.
This at least reduces the problem to one of credit card fraud, but in the common case establishes proof of ownership for the keypair of the buyer. Should something like this ever come to court, additional data (IP logs, etc) could be used to further establish ownership of the transaction.
This protocol seems straightforward to implement in a way invisible to the end user in client software like the Amazon downloader or iTunes, but it might be hard to do on the web. Some combination of AJAX and browser-based certificates could do the job (if it weren’t for everybody being afraid of browser-based certificates).
While still being a grim case for copyright infringers, I believe it solves the problem BlueParrot pointed out and makes watermarking as a form of DRM safer for the buyer. As always, please point out flaws in the protocol.
Update: 12/31/2007: I believe the credit card processing requires a mutually-trusted third party for this to work without IP log subpoena.