B&N EPUB key derivation algorithm

I’ve managed to figure out the Barnes & Noble user EPUB AES key derivation algorithm. Rather than fragment things too much, I’ve just edited my previous post on B&N EPUBs and added the (for any platform) key-derivation script.

The algorithm is interesting mostly in that it isn’t very good. I mentioned in my post analyzing Adobe’s ADEPT system that ADEPT is a fairly well-designed cryptographic system, even if not a very effective DRM system. Adobe used all standard algorithms applied in standards ways and glued together with standard plumbing. Barnes and Noble’s key derivation algorithm in contrast is neither effective at increasing obfuscation nor shows much awareness of cryptographic standards.

Cryptography is hard. Do you know how different configurations of your chosen algorithms can make them more or less resistant to side-channel attacks? Do you understand why RSA Laboratories switched the recommended RSA padding scheme in PKCS#1 to OAEP? Do you know the implications of different block cipher modes of operation and why or why not you should choose a mode which includes integrity protection? These questions represent a random sampler platter of things you should just know in your bones before you do anything close to designing a cryptosystem. For everyone else – a category in which I include myself – there are well-reviewed, well-tested algorithms presented in standards documents published by such organizations as RSA Laboratories and the IETF.

For key derivation from non-random source data, there is in particular the PBKDF2 (Password-Based Key Derivation Function) published in PKCS#5. My point is not that the key-derivation algorithm used by B&N necessarily has cryptographically undesirable properties (although its computation speed makes brute-force attacks more plausible), but that the fact that they rolled their own instead of reaching for PBKDF2 shows a marked lack of cryptographic savvy.

On the DRM-as-obfuscation end this algorithm similarly come up short. The multiple steps involved demonstrate some level of attempt to introduce complexity, but in the resulting binary all those steps are in one place. The entire algorithm boils down to one function calling a handful of easily-labeled subroutines (sha1_wrapper, normalize_name, aes_encrypt, etc).

I really am starting to think that e-book format providers actively want their DRM schemes to be broken.

Circumventing Barnes & Noble DRM for EPUB

In a move sure to leave consumers scratching their heads (especially the ones already wondering why they bought a Nook), Barnes & Noble has decided to implement their own DRM scheme for EPUB books. They partnered with Adobe to do it (it’s a variant of their ADEPT scheme), and all the Adobe SDK users will get access to it eventually. But for now much hilarity ensues as consumers buy books they can’t read on their devices.

The basic idea behind the B&N EPUB scheme is the same as that used by the ill-fated eReader format B&N acquired – step 1: generate an encryption key from the book-purchaser’s name + credit card #; step 2: hope that they don’t like giving that information out to strangers. They like to call this a form of “social DRM,” although I believe a more appropriate term is “silly.”

It would be very bad form for an application to keep user CC#s just sitting around on disk, so the Windows version of the Barnes & Noble Desktop Reader application (BDReader) just holds on to the generated key and not the source info. A wise decision, for which I congratulate them. It then stores this key in plain text in a sqlite3 database. An... interesting... decision, for which I thank them. Update: and then it turned out the key-generation algorithm was pretty easy too...

So now three scripts:

A Windows-only key-retrieval script: ignoblekey (version 2)

An any-platform key-generation script: ignoblekeygen (version 1)

And an any-platform book-decryption script: ignobleepub (version 1)

You need the decryption script and one of either the key-retrieval or key-generation scripts. They produce the same output, and the key-generator works on any platform, but I released the Windows key-retrieval script first and will leave it up for Windows users who’d rather not give their credit card number to random programs they download off the Internet (despite being a source-visible script and all).

For good only, please.