eReader.com vice president and general manager Mike Violano shares his (perhaps slightly biased) views on digital rights management DRM in an article (http://www.localtechwire.com/article.cfm?u=9433) published at LocalTechWire.com.

First he explains how DRM works at eReader.com: Every ebook is encrypted and the unlock key is the credit card number the customer uses to purchase the title. This has proven to be a simple, elegent approach to the protection of content—and it is mighty effective since customers are not prone to post their credit card numbers on the message boards.

Compared to competing formats such as encrypted PDF or .LIT, one advantage of eReader DRM, he goes on, is that it does not prevent the customer from moving his e-book from one device to another. Plus, eReader books stay available for download in an online bookshelf for an unlimited time (unless eReader.com goes bancrupt or is sold to another company, I'd say).

What is most interesting about this article is its last part, on the future of DRM. Mr. Violano agrees that DRM is still a troublesome obstacle for customers, at least the way DRM is currently implemented:

The technology must be friendlier at every step along the way. We are constantly innovating to improve the customer experience and simplify the process while respecting the copyright owners.

Even the best designed DRM technology, rights expression language, or the most finely crafted standards will fail if the customer experience of the content is disregarded. Technology must be the enabler, guiding all the explorers—publisher, etailer and customer in the journey—the quest for content and enjoyment of that content in all digital forms.

Nicely put!

There are 2 major problems with this DRM:
- you cannot redownload your eBooks to get them encrypted for another credit card. ... change your bank, and loose your eBooks !
- the system does not work with the "e-credit cards" system, now widely used in Europe. The bank gives you a unique temporary credit card number when you ask for one. This prevents from using your real credit card number for purchases on the Internet. For each eBook you purchase, you have to write the credit card number you have used to get it ! And the bank does not store the generated card numbers... so if you forget it, you can't do anything.

Finaly, this DRM is just a "password-based" system. What does happen when an eBook is sold with a stolen credit card number ? What can prevent the hacker from putting the eBook + the CC number on any website ?

The only valid system is a "device-based" DRM where the customer can download again eBooks for any new device (provided that the Reader runs on this new PDA/Smartphone).

This is the most assinine method of "protecting" an electronic work I have ever seen.

When (not if), this encryption method is breached, the ability to get the credit cards numbers back out of the system will be immediately made publically known. Whomever thought of this method needs to be drawn-and-quartered (http://en.wikipedia.org/wiki/Drawn_and_quartered).

Secondly, you can just as easily take a PayPal credit card account, or a Debit Card account (http://en.wikipedia.org/wiki/Debit_card), open one up at a bank, put $20.00/USD in it, and purchase the book, under a false or forged name if you wish. Once you get one of eReader.com's works, with the "credit card" number out there for others to poke and prod at, reversing this encryption method becomes possible.

Using "encryption" for DRM (http://en.wikipedia.org/wiki/Digital_Rights_Management) is a braindead, non-scalable solution. Now, to properly solve this problem, they could take the credit card number, hash it with a specific seed, such as the name of the book and purchase date, then md5 (http://en.wikipedia.org/wiki/Md5) that, and apply that as the key.

Since md5 has something like 340282366920938463463374 (1<<128) possible hashes, and is imposslble to "decrypt" (because it is encoded (http://en.wikipedia.org/wiki/Text_encoding), not encrypted (http://en.wikipedia.org/wiki/Encryption)), you can now properly secure the book, using a purchaser's credit card, and not expose their actual card to anyone who happens to break the weak encryption method that eReader.com is using. Encryption algorithms are being broken all the time. With faster, more-capable computers, this becomes easier and easier. A one-way hash (http://en.wikipedia.org/wiki/One_way_function) is the only secure way around this.

The other problem with this solution, is that it does not scale, when the encryption method is broken, and eReader.com has to replace it with another solution, all existing copies of purchased works immediately break, because the checking that the application must do now uses a different method. Sure, it can use both, but now you have to deal with two sets of registration "keys" for the two kinds of material that you purchase through eReader.com.

I'm all for protecting the rights of copyrighted works and the authors of those works, but the only people who suffer from implementing these poorly thought-out methods, are the innocent people.

And lastly, lets not forget that DRM does not stand for "Digital Rights Management", it stands for "Digital Restriction Management". It doesn't manage your rights in any way, because it doesn't give you any additional rights, it takes them away.

I'll be staying away from anything eReader.com produces, and I'll be strongly recommending to users and all of my clients to do the same.

When (not if), this encryption method is breached, the ability to get the credit cards numbers back out of the system will be immediately made publically known. Whomever thought of this method needs to be drawn-and-quartered (http://en.wikipedia.org/wiki/Drawn_and_quartered).
(edit: sorry hacker. I didn't see that you were going to explain details of hash functions as well. my fault!)

It is fortunately not that bad. eReader uses some kind of one-way hash algorithm in conjunction with the credit card number. Hash algorithms are central to modern cryptography. The security of a one-way hash function is its one-wayness: the output is not dependent on the input in any discernible way. Plus, given a hash value, it is computationally unfeasible to find a pre-image that hashes to that value.

After eReader has created and stored the hash, it uses it as a key to decrypt the protected e-books (which are, to my knowledge, encrypted with the DES-X algorithm).

The credit card number isn't stored, neither in the e-book nor on your pda device - at least eReader claims so, and I don't see a reason why they should lie.

The credit card number isn't stored, neither in the e-book nor on your pda device - at least eReader claims so, and I don't see a reason why they should lie.

If the credit card number (or the result of the computation you explain) isn't stored, then why aren't you asked to enter the credit card number each time you open the eBook?

Are you asked to enter the CC each time? To my knowledge, it only asks you once - before you have activated the book.

"After eReader has created and stored the hash, it uses it as a key to decrypt the protected e-books (which are, to my knowledge, encrypted with the DES-X algorithm)."
If its a one-way hash, there is no "decryption" involved. You simply take the password/key/code that is entered, encode it with your known seed + hash, and compare it with the stored value. If it matches, access is granted. If it does not match, access is denied. This is how the standard Unix (and Linux) username:password login authentication is handled.

If there is a key of some sort, which is used to encrypt and decrypt the book, and that is stored somewhere in the application or the book itself, then the whole process of encryption is irrelevant, and can be easily bypassed, using any one of dozens of different techniques to bypass the check for the proper code (witness the thousand of Palm applications that have been breached because they use this method of "securing" their application).

Regarding entering the credit-card-as-key every time, I think what was meant was that the value you enter the first time, has to be encoded, encrypted, or stored somewhere within the book metadata, so that it can be checked and verified every time you launch the reader to read the book. The mention that the credit card value is not stored anywhere is completely false, if this is how their application works.

If you have to enter the key every time you open the book, then it would appear that they aren't storing the key anywhere. If you don't have to enter the key every time, then it is stored, somewhere, in some format, which is queried and used to authorize reading of the book.

That is the point Mobipocket is making. He claims that the credit card must be stored somewhere if it doesn't require you to input it each time you read it. However, I think MobiPocket must not have had his coffee yet, for he usually knows better. An application doesn't have to store the actual password in order to remember that it has received a valid one in the past. It just needs the accompanying hash and a bit-set saying "mission accomplished" somewhere. eReader will be hacked when they find this bit.

That is the point Mobipocket is making. He claims that the credit card must be stored somewhere if it doesn't require you to input it each time you read it. However, I think MobiPocket must not have had his coffee yet, for he usually knows better. An application doesn't have to store the actual password in order to remember that it has received a valid one in the past. It just needs the accompanying hash and a bit-set saying "mission accomplished" somewhere. eReader will be hacked when they find this bit.


If what you are saying is right, then, it means the file is decrypted (either the "accomplished" flag is stored inside the book itself, or in a file near the book), but the fact is that the decryption is mainly done... ie one can copy/paste the files on another PDA to read the book... Where's the DRM here ?

I've got some eReader ebooks, and I think this is the idea...

* When you purchase the ebook, you supply a credit card number.
* That CC# is required to unlock a book file and read it.
* When you enter the CC#, it is converted into a hash value that is stored on the device. Any ebook purchased with that CC# is now available without re-entering. This means, for example, you could "loan" the book to someone by entering the CC# for them on their device. They never know your # and only the hash value is stored, so no one can reverse engineer the CC#.
* Additionally, you can re-download eBooks you have purchased from their online store. (Yes, that depends on them still being in business and supporting that service, so it's probabaly not permanent.)

My main problems with this DRM are:
1) I have to keep track of the CC#s used to buy each book.
In fact, you have to pick the right CC# for the right book, so if you have multiple books and multiple CC#s it can take a lot of number grafitti. But thankfully, once entered, it's good for all applicable books.
2) It's still a DRM, which means that as technology changes (or I change technology), the book is no longer really readable unless eReader decides to support it.

But of all the DRM schemes I've seen so far, I think this is the best compromise. It prevents widespread copying, and it also allows some reasonable flexibility to the user.

I don't think anyone has solved the ""ownership issue" -- your use of the book is dependent on support of a particular technology. Until that gets solved, I don't think eBooks will do well, except maybe novels and things that you read once and throw away. No one in their right mind will spend a lot of money on reference sets unless they are willing to consider them disposable.

Edit: BTW, I also talked with the folks at eReader about this CC# issue before I bought the books. There's another thread on that here somewhere, but don't have time at the moment to go find it.

The "bit" is probably stored in system preferences. Otherwise, it wouldn't need to be re-keyed when you move it to a new device. The bit may even be a hash itself, but I am not familiar enough with the eReader DRM method.

Anyhow, it is really not that big of deal. Why would someone have my coded eBook? There is no point in sharing them across the net. Only my immediate family shares them. So, its not like the world would know my credit card number even if someone managed to reverse-hash an eReader book.

The eReader will get hacked not by extracting the credit-card number, but by extracting the text once it is keyed. I am sure there are macros that take snapshots as each page is displayed on the desktop, and then sends the very clean "scans" to an OCR program. Heck, you could just dump the screenshots to Adobe for a PDF document if you like (not suitable for Palm reading, though).

It won't be long until eReader has to update their DRM scheme as well. That's just how it is in the digital society.

My main problems with this DRM are:
1) I have to keep track of the CC#s used to buy each book.
In fact, you have to pick the right CC# for the right book, so if you have multiple books and multiple CC#s it can take a lot of number grafitti. But thankfully, once entered, it's good for all applicable books.


Actually, they solved that by allowing you to "re-encode" your library that is on the web and all you have to do is re-download. I've been using them for quite a while.

I'm sure there are going to be ways to crack it, or even "screen scrape" the device to extract the text. I suspect that for most book titles, it just isn't worth it.

I have an even better idea, and works throughout all industries...Vote with your wallet!
Seriously. If the vendor doesn't support your morals, or your preferred format, or makes it difficult to read the material on your device, just don't buy it. Or, buy it from another vendor. Once they start seeing a large drop in sales, they'll do what it takes to retain their existing customer base.

Or, they'll just die off because they're too arrogant to see what needs to be done to change. Either way, the customer benefits, and it drives up competition amongst competing vendors for the same client base.

And remember, we are customers, not consumers.

If its a one-way hash, there is no "decryption" involved. You simply take the password/key/code that is entered, encode it with your known seed + hash, and compare it with the stored value...If there is a key of some sort, which is used to encrypt and decrypt the book, and that is stored somewhere in the application or the book itself, then the whole process of encryption is irrelevant... Not right here. The hash value resulting from the one-way hash is the actual key to encrypt/decrypt the book.

I am currently working on a small flowchart to show how the DRM process could look like.