pass phrase features (vulnerabilities) by design

[eshellman]

My understanding of LCP has been greatly assisted by the responses to the issues I've filed, I hope they will also help improve the documentation of this important project.

Given my previous misunderstandings, I'd like to confirm what I take to be a designed-in feature that some might view as vulnerabilities.

When a document has been provisioned with LCP, it is locked to a user's pass phrase. There is nothing to stop a user from sharing the document, along with their pass phrase, to a small number of friends. This sharability mimics that of iTunes DRM, with the exception that disincentive for oversharing a pass phrase is only the risk of having the associated license(s) deactivated.

Further, there is nothing in the spec that prevents users from choosing weak pass phrases; and implementation of passphrase restrictions could threaten inoperability.

Imagine that for privacy reasons, users were encouraged to choose a weak pass phrase like "privacy rocks". This would not cause problems for the users so long as they did not share their documents, and would prevent providers from using the pass phrase to track users. It would be better for users concerned about privacy to use a password manager to assign a different, strong pass phrase for every document. (Tracking with pass phrases only impinges on privacy if providers start to share (hashed of course) user ids, because we assume that providers will already have authenticated their users somehow.)

So a scenario where protected documents (all with the same pass phrase) are loaded onto an unauthorized distribution site is not prevented by LCP. The reason not to worry about this is that any sophisticated pirate would be assumed to be able to crack any encryption no matter what and would just distribute decrypted files.

I can think of two plausible reasons for an unauthorized distributor to prefer encrypted files.

1. legal cover: the sharing is only what's "allowed" by the encryption.
2. anti-DRM hacktivism: the distributor hopes to place a burden on the license invalidation mechanism. I think both of these reasons are uncompelling, and I doubt that there will be any organized distribution of encrypted files.

Is this accurate?

[HadrienGardeur]

That's a fair description overall, but I'd like to add a few notes:

• I don't believe that most retailers/libraries will let users decide what that passphrase is. It's of course a possibility, but so far that's not the plan for early LCP adopters.
• at the same time, it is indeed possible to generate a unique passphrase per license. This is what I expect some library software (SimplyE being one of them) to actually do.
• LCP is also designed with better UX than proprietary DRM in mind, which is why random passphrase are IMO only a valid option if and only if:
  1. this User Key is automatically exchanged in the background, for example between a library's OPDS catalog and a reading app
  2. if the use case is limited to loans and not acquisitions
• you're also right that if a DRM can be cracked (and all DRM are eventually cracked, usually sooner than later), it makes absolutely no sense to organize distribution of encrypted files

[billrosenblatt]

To Eric’s points about distributing encrypted files along with passphrases:

1. This AFAIK hasn’t been tested in the courts, but it has been argued that #1 (supply lots of encrypted files along with their passphrases) doesn’t give you any legal cover, because it’s just another way of circumventing the DRM. Nothing in the law says that circumvention = hacking.*

2. This strikes me as a silly way to bring a DRM system to its knees. There are other less silly ways.

I agree with Hadrien that distributing lots of encrypted files with their passphrases (whether one or many) is not a serious threat.

• Bill.

*The context in which this has been previously brought up was Kim Dotcom’s post-MegaUpload MEGA system. Files are encrypted, users set their own passwords on files they share, MEGA gets plausible deniability by not knowing what the passwords are, and the liability shifts to users who make their passwords publicly available. Would be infringers (I don’t like the P-word) figured this out and avoided MEGA in droves.

From: eshellman [mailto:notifications@github.com] Sent: Monday, March 20, 2017 6:29 PM To: readium/lcp-specs Cc: Subscribed Subject: [readium/lcp-specs] pass phrase features (vulnerabilities) by design (#9)

My understanding of LCP has been greatly assisted by the responses to the issues I've filed, I hope they will also help improve the documentation of this important project.

Given my previous misunderstandings, I'd like to confirm what I take to be a designed-in feature that some might view as vulnerabilities.

When a document has been provisioned with LCP, it is locked to a user's pass phrase. There is nothing to stop a user from sharing the document, along with their pass phrase, to a small number of friends. This sharability mimics that of iTunes DRM, with the exception that disincentive for oversharing a pass phrase is only the risk of having the associated license(s) deactivated.

Further, there is nothing in the spec that prevents users from choosing weak pass phrases; and implementation of passphrase restrictions could threaten inoperability.

Imagine that for privacy reasons, users were encouraged to choose a weak pass phrase like "privacy rocks". This would not cause problems for the users so long as they did not share their documents, and would prevent providers from using the pass phrase to track users. It would be better for users concerned about privacy to use a password manager to assign a different, strong pass phrase for every document. (Tracking with pass phrases only impinges on privacy if providers start to share (hashed of course) user ids, because we assume that providers will already have authenticated their users somehow.)

So a scenario where protected documents (all with the same pass phrase) are loaded onto an unauthorized distribution site is not prevented by LCP. The reason not to worry about this is that any sophisticated pirate would be assumed to be able to crack any encryption no matter what and would just distribute decrypted files.

I can think of two plausible reasons for an unauthorized distributor to prefer encrypted files.

1. legal cover: the sharing is only what's "allowed" by the encryption.
2. anti-DRM hacktivism: the distributor hopes to place a burden on the license invalidation mechanism. I think both of these reasons are uncompelling, and I doubt that there will be any organized distribution of encrypted files.

Is this accurate?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/readium/lcp-specs/issues/9 , or mute the thread https://github.com/notifications/unsubscribe-auth/AMGE_mFOL4nXoasbY2aDjDDjJ__OEWO-ks5rnv2agaJpZM4MjGOp . https://github.com/notifications/beacon/AMGE_ruLJeEDAVsP4nYtdTH47RdcayKsks5rnv2agaJpZM4MjGOp.gif

[eshellman]

Thanks! I agree with what Bill and Hadrien have said. Will leave the issue open for a day or two then close in case anyone else wishes to comment.