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.

Circumventing Kindle For PC DRM (updated)

Amazon actually put a bit effort behind the DRM obfuscation in their Kindle for PC application (K4PC). The Kindle proper and Kindle for iPhone/iPod app both use a single "device" encryption key for all DRMed content. K4PC uses the same encryption algorithms, but ups the ante with a per-book session key for the actual en/decryption. And they seem to have done a reasonable job on the obfuscation. Way to go Amazon! It's good enough that I got bored unwinding it all and just got lazy with the Windows debugging APIs instead.

So here you go: unswindle v7 (previous versions: v6 v5 v4 v3).

You'll also need a copy of darkreverser's mobidedrm (check the most recent comments for the newest links).

Put those kids together (in the same directory) and run unswindle.pyw. It launches KindleForPC.exe. Pick the book you want to decrypt. Close KindleForPC. Pick your output file. And enjoy the sweet taste of freedom.

Script name in honor of rms and The Right to Read. Don't use this to steal, or I'm taking my toys and going home.

Updates. It came to my attention that unswindle version 1 did not work if KindleForPC was installed as a non-administrator and did not work on versions of Windows other than XP. Version 2 should fix these issues. Version 3 fixes an intermittent path-getting issue. Version 4 fixes an exception related to opening thread handles, detect Topaz format books, and detects that you have the proper version of Kindle For PC installed. Version 5 works with the new (20091222) version of the K4PC executable. Version 6 cleanly handles already DRM-free files.

Update 2009-12-22. Amazon has demonstrated that they (unlike Adobe) take their DRM seriously: they've already pushed out a new version of K4PC which breaks this particular script. As you can clearly see via their SHA-1 hashes:

fd386003520f7af7a15d77fcc2b859dd53e44bc1 KindleForPC-installer-20091217.exe

13a816a3abf7a71e7b6a55228099b03b1dc3789b KindleForPC-installer-20091222.exe

The application doesn't seem to auto-update, so if you can find a copy of the original installer you should be fine. Otherwise you'll have to hang tight. Newest unswindle version detects if you have the wrong K4PC executable installed.

Update 2009-12-22 (2). The K4PC update may not actually have been targeted at unswindle, as Amazon seems to have done nothing in particular to make the basic approach more difficult. In any case, I've updated unswindle to handle the 20091222 version of the executable. We'll see if Amazon throws out another new build in short order, and I'll put some more elbow grease into figuring out the PID-generation algorithm.