Not clear how decryption is restricted

[eshellman]

Having read the spec, I can't figure out what mechanisms, if any, are used to restrict decryption of the protected content. The license includes the content key, encrypted with the user key, so it seems there's nothing preventing the software from just decrypting the content. There is discussion elsewhere of certifying software and verify its "hardening", but that implies there remains an additional secret that unlocks either the content decryption or the key decryption. It's not possible to evaluate the impact on reader usability or privacy without understanding how this additional secret is to be handled or generated. If I've misunderstand the intent, I'd be happy to help make the document clearer to those who have not been involved in its drafting. Thanks for this work.

[HadrienGardeur]

I'll let @llemeurfr reply but the additional crypto materials has absolutely zero impact on privacy.

[billrosenblatt]

That’s right, you need a digital certificate and a static piece of code, which are supplied through EDRLab. They both just verify that your app is licensed in the Readium LCP ecosystem; otherwise they have no impact on UX or privacy. They are validated in order for the decryption to work. In addition and separately, you have to agree in the license agreement to obfuscate your code to make it harder to reverse engineer, given that almost all of it is open source. Again this doesn’t impact UX (unless your obfuscator screws up your code…).

[eshellman]

@HadrienGardeur as you know, the "additional crypto" in ACE is known to incur a privacy risk. In the absence of details, it's not easy to imagine how license revocation is to be accomplished with "zero" impact on privacy.

[llemeurfr]

Hi Eric, let's summarize: A user knows a passphrase (something he has chosen or which has been given to him by a license provider). The soft transforms the passphrase into a user key (uk = f(pp) then hashed). The userkey can decrypt the content key provided in the user license. The content key can decrypt the content.
The soft is mostly open-source, only uk = f(pp) isn't (in the open-source version it is void). Only trusted licence providers and trusted app developers know what this string transform is. Therefore one cannot take the open-source software and simply add a "save as clear epub" feature applied on ebooks provided by certified servers. Certified applications must be hardened, so that hackers don't easily find the secret function.

Re. privacy (as I understand this is your main interest): The provider doesn't know the passphrase (potential personal info), only the user key passed to him by the bookseller or public library (the creation of the user key is done on their website). The bookseller MAY add some personal info to the license provider for inclusion in the license, but the license provider cannot keep it and it must encrypt it in the license. The client does not send private info to the server (see the License Status Document spec about client-server interactions), only requests for action like "register" (device), "return" and "renew" (lending).

[llemeurfr]

@eshellman can you give more info about this "additional crypto" in ACE and its privacy issues?

Re. LCP, if the e-reader is connected to the network, it sends a "register" request to the license server the first time it opens a book, with an app and device id (but NO personal info). A license revocation will happen (as a reaction from the provider) if the number of registered devices climbs to the sky, which would be the case if a protected file is sent into the wild with the associated passphrase.

[eshellman]

@llemeurfr Thanks, that helps a lot. I would note that device ids can be used exactly like tracking cookies and the reader's anonymity is easily pierced.

@billrosenblatt note that it's not just the f(PP) code that requires obfuscation, but also the user keys. Doing both is hard, and the effect on UX is certain; for example in a web-based reader such as epub.js.

[billrosenblatt]

@eshellman bear in mind that LCP is only designed to be used with Readium, not other EPUB readers.

[llemeurfr]

@eshellman note that we don't intend to have in-browser Readium LCP implementations, e.g. in the Readium Cloud Reader. This DRM is targeting desktop and mobile apps. On the Web, we feel that a proper authentication makes hat is needed. At least this is our present stake.

Re. device ids, note that each license provider has only records about the licenses it delivers. Data is therefore largely distributed.

[eshellman]

@billrosenblatt so LCP can't be used for reading accessibility tools?

[llemeurfr]

@billrosenblatt mmh what do you mean by that? LCP can be integrated in non-readium-based apps, especially e-readers and specific accessible readers (Humanware type).

[billrosenblatt]

@llemeurfr https://github.com/llemeurfr so you can have a licensed LCP implementation in a non-Readium-based app? If so, I stand corrected.

[HadrienGardeur]

@billrosenblatt so LCP can't be used for reading accessibility tools?

LCP can definitely be used by reading accessibility tools, the goal is to even add LCP support to dedicated hardware.

@llemeurfr Thanks, that helps a lot. I would note that device ids can be used exactly like tracking cookies and the reader's anonymity is easily pierced.

That's partially correct.

LCP has no central server, no account system but a distributor could identify that two different books have been read by the same device. That said, the distributor won't have any additional info aside from this device identifier and an IP address.

Once could also design an LCP client that maximizes privacy, for instance a dedicated library app (let's say SimplyE) could send a random id or use several id to make such tracking harder. It could also rely on a server instead of the client app to handle such registration, acting as a proxy to make sure that the IP address is not collected.

I don't think that this would go against the certification process that EDRLab will handle.

[eshellman]

@llemeurfr Will there be documentation forthcoming for the "register" process you mention? or is that meant to be outside of the standard? Will there be any prohibition on sharing registration data among providers? (Because that's what cookie-based trackers do.) While NYPL would try not to share this sort of data, the fact is they were placing advertising network cookies on their catalog until I convinced them to stop.

[HadrienGardeur]

@llemeurfr Will there be documentation forthcoming for the "register" process you mention? or is that meant to be outside of the standard?

It's already fully documented at http://readium.github.io/readium-lsd-specification/#33-registering-a-device

[llemeurfr]

@eshellman prohibition on sharing registration data among providers is an interesting privacy protection and I'm ok to add it to the terms of use (even is it is impossible to control on our side).

[eshellman]

@HadrienGardeur Thanks! I saw that part but I didn't understand the description of its purpose. I will submit a separate issue about that because the registration process presents a number of potential vulnerabilities.

[eshellman]

The information from @llemeurfr provided in this issue thread would make the spec much easier to understand. Could it be included in the spec somehow?

[HadrienGardeur]

It's not really relevant to the spec though, this is tied to an encryption profile.

I'll file a new issue about registry documents, this would be the relevant place to have such info.

[llemeurfr]

I've added some more information from this thread in https://www.edrlab.org/readium/readium-lcp/principles/