The following question comes from Sue Polanka of No Shelf Required:
What do you know about B&N embedding the name/credit card number into ebooks purchased for the nook? Is there a way around this? Are they still doing it? This is a concern for libraries who choose to circulate the nook, since the library credit card number is in the file. Although, I’m not techie enough to know how to get into the file and find the number. Any idea how?
The credit card number and name are used to generate a key. This is a one way process. You cannot use to key to generate the credit card and name the key was created with.
When you download a book the key is generated and enclosed within the e-book file.
When you open a book encrypted with a key that the Nook does not know yet, the book will ask for a credit card number and name and generate a key that is saved on the Nook.
This is a secure system. Only a key is saved, that cannot be used to extract your credit card number and name.
Books purchased from B&N do not embed the credit card information. They embed a one-way hash of half the credit information combined with the name. While it seems possible to brute force that half-number using a known name (at a maximum, it would only take 100,000,000 tries as there are eight digits), I don’t know if anyone has done so and the information would be of limited use.
Books borrowed from Overdrive/the library use traditional, centralized Adobe keys that do not include the credit card. Thus, nooks borrowed from the library would not be associated with any credit card under traditional lending. (I suppose a library could buy a device, purchase books for that device outside the Overdrive system, and lend it out, but, if they could do that, why does HarperCollins have any say on lending?)
And it’s worth pointing out that the folks B&N got their DRM system through, Fictionwise/eReader, have been using it ever since eReader was first founded as Peanut Press almost 15 years ago, without any security issues ever arising. The original idea, which was mentioned at the time, was that while people might copy books for close friends and unlock them on their devices (in fact, the way that a major gimmick of the default method for reading e-books back then, the Palm Pilot, was beaming files back and forth through infrared, this was how they imagined it happening), they would be reluctant to share something so personal as their credit card information by posting it wider.
This was, of course, back in the innocent time when publishers completely trusted DRM and thought of it as an effective way to protect e-books (i.e. the only way that the e-book could possibly be shared with someone else was if they shared the credit card number along with it) rather than the hastily-adopted “speed bump for the honest” fallback position. Ah, those were the days.
Just to reinforce Logan’s point above — the embedded hash also only uses PART of the credit card number (plus the name). You can’t generate the full credit card number working backwards from the hash.
It’s not unlike when your bank sends you letters or emails referring to “your account ending in ____.” It’s enough information to provide a key to the DRM, but not enough that someone could go on a spending spree.
what happens if you change your credit card number and then need to port the book to another device? do you need the same CC#? after a few years, it would be a pain to have to remember which CC# you used to purchase which book.
@becca, you can change the card # and re-download from B&N’s site or you need to remember the old card #.
@becca: …or you can remove the DRM….
The pain of having to store old card numbers or re-download is why I stopped buying DRMed ebooks for about five years.
N.B. B&N’s ePub encryption scheme /does/ use all 15/16 numbers of the CC#. But I think Logan is wrong to suggest that even with 8 digits used it would be possible to brute-force the original digits from the hash. The hash function is lossy. You’d end up with many possible card numbers, not just one.
Thanks to everyone for their responses. Most helpful. Sue
Purchase – strip DRM – make backups – lock’n load.
Listen to Paul, he would know.
I’ll have to go back and revisit the Adobe “password”-based DRM, as I thought, like Fictionwise, that it only used a portion of the number.
I’ll also have to re-examine the collision properties of the hash. Not all credit card numbers are valid and if they are truly using all the numbers, then it could be possible to simply identify the valid one based on the institution identifier (if you have knowledge of the target).
In any case, your credit card number is not stored in the book, and, based on our current understanding, it is not feasible or practical to attempt to extract any information.
Paul: The official app does require you to type in all 16 digits, but the hash is only generated and decrypted from the latter 8. (Early versions of the app would let you just type in the last 8, but they subsequently decided to ask for the whole number even if they didn’t really use the whole thing. That whole naive “keep people from sharing by making them have to share their whole credit card number along with it” thing again.)
However, the various eReader DRM-stripping apps, such as eReaderPDB2PML.pyw, only require the last 8.
“However, the various eReader DRM-stripping apps, such as eReaderPDB2PML.pyw, only require the last 8.”
The apps/scripts for Adobe Password based DRM (which is what B&N uses now) also only require the last 8.