Sol Reader DRM

TL;DR: We’re publishing our own open simple eBook DRM standard. We built it for Sol Reader but it could be used by others as well. We would love your feedback!

We did not go into building Sol Reader expecting to build our own DRM standard. In fact, I’m not sure if I ever envisioned myself building DRM software. I assumed this surely was a solved problem and there was some standard we could hook into. Surely we can just use someone else’s DRM standard. Right? RIGHT???

XKCD 927: A classic

But here we are, in late 2024, building DRM for eBooks. The reason is very simple. Our product is not based on iOS/Android/Mac/Windows. We also aren’t Amazon or Apple. So none of the existing DRM solutions work on our very unique eReader product. And to our knowledge there is no fully open eBook DRM standard out there (but please, if you are building this, let’s be friends). Here’s what exists:

• Amazon’s Kindle AZW & KFX DRM. Only works on Amazon’s devices and apps. They haven’t ever allowed anyone else to use it. Though it’s been thoroughly reverse-engineered to the point where you can remove it with only your Kindle’s Serial Number.
• Adobe Digital Editions DRM. Outside of Amazon, this is the closest to an industry standard that exists. Kobo and Libby use this. But, you have to use Adobe’s SDK to render the content, which might be ok, if you have a platform they make an SDK for (i.e. iOS/Android/Mac/Windows). It also costs >$20k / year to use plus a per book fee. It’s also been thoroughly reverse-engineered to the point where it is very easy to remove.
• Apple Fairplay DRM. Apple does not share this kind of thing. Ever. No surprise there. But it’s actually quite secure with no known way to remove it.
• Readium LCP. This is the DRM we wanted to use. Their standard is mostly “open” in that they document it and have some partial implementations that are open source. But the key transformation is handled by a proprietary library that they only compile for iOS/Android/Mac/Windows/Linux. If you are not using one of those platforms you are out of luck 😭

Publishers in the US are losing something like ~$300 million annually from book piracy. We like books, and we like authors to get paid. But the state of eBooks is similar to that of music in the heyday of Napster in the early 2000s –the technology is disjointed and many find it easier to pirate the content than to buy it.But Napster died and music piracy has diminished over the years. Why? Because the usability and technology behind music streaming services like Spotify are ubiquitous, reasonably priced, and work everywhere. We would love a future where it’s similar for eBooks. So we are creating and publishing a standard that meets the following goals:

• Not based on security-through-obscurity. Every other DRM out there that we know of relies on at least some part of the system remaining a secret. We’d rather let anyone understand it (and please, please tell us how to make it better). If this security model is good enough for other modern standards like HTTPS, it’s probably enough for eBooks.
• Simple & Efficient. Sol Reader is a very low-power embedded system (which is why we get 20-30 hours of battery life on tiny batteries) so our standard needs to be able to run on a low power system and not require full copies to RAM or disk of the entire eBook. It also needs to not balloon the file size by messing up compression (EPUB files are zip files and encrypting the contents of a zip absolutely wrecks the ability to compress it).
• Meets or exceeds industry standards for copy protection. Though industry standards here are admittedly pretty poor–with the exception of Apple’s Fairplay DRM—all the other standards out there are pretty trivial to decrypt & strip.
• Based on EPUB3. Because standards are good. We also wanted to keep the metadata and non-content data unencrypted (e.g. we add LLM-generated summaries and glossaries to our EPUBs by default).

Here’s what we came up with. It’s roughly a mash-up of HTTPS-style public key cryptography and EPUB3.

How does it work?

A client supporting Sol DRM generates an RSA keypair of at least 1024 bits. Why 1024? Because it’s pretty hard to brute force (much much harder than 512 which is pretty easy) and can be generated on our 240MHz low power processor in ~4s. The private key is stored in the platform’s secure credential store (e.g. Keychain on iOS). When downloading content, the public key PEM is sent to the server.

The server sends back a Sol DRM protected eBook as an EPUB3 file with the following modifications:

• A sol_drm.key file exists at the root of the EPUB3. This file contains the encryption type, and the RSA-encrypted AES key in this format. The Device’s private key can be used to decrypt the AES key, which is in turn used to decrypt the content.
  

• A rights.xml file TBD
• All content html/xhtml files (as listed by the OPF spine) are compressed, then AES encrypted, then prepended with a header:
  

For a client to decrypt the EPUB, the flow would be something like this:

1. Parse the sol_drm.key file. Use the client’s saved RSA private key to decrypt the AES key.
2. Load the EPUB spine from the `.opf` file to get the list of content files in the book (like you would normally when reading an EPUB).
3. Open the first EPUB content file (pro tip: remember EPUBs are zips? Many zip libraries allow you to open internal files inside the zip without fully unzipping the file)
4. Parse the content file header.
5. Use the included AES nonce and AES tag, as well as the decrypted AES key from step 1 to decrypt the content.
6. Decompress the content using ZLIB DEFLATE.
7. Parse the html content as you normally would in an EPUB.

Both the Sol Reader and our mobile apps are using Sol Reader DRM

Limitations & Future Work

This standard just covers the copy protection of the EPUB file itself. It is up to the client implementation to keep the private key private using whatever secure keychain technologies are available (e.g. Keychain on iOS). And eBook DRM standards don’t usually specify user authentication, and we’re treating the public key management as subordinate to that – if you are logged in to our service, and you provide us a public key and request a book you own, we will send you back an encrypted EPUB.

In the future, it could be awesome to have an interoperable system to prove purchases and ownership as well. Maybe there’s some blockchain-y way to forever prove you own a piece of content in an immutable way. But that’s a project for another day.And that’s it! It’s pretty simple, we think. And it adds only milliseconds to our epub parsing time, despite being probably 🤞harder to crack than Adobe & Amazon’s DRM. If you see flaws in our design, please tell us in the comments or on our Discord!