Analysing ADEPT (Adobe Digital Experience Protection Technology)

Or... How DRM invades your privacy, and why this doesn't have to be the case.

ADEPT (Adobe Digital Experience Protection Technology) is the DRM (Digital Rights Management) system developed by Adobe to protect ebooks. The description below is based on the Adobe Content Server 4 User Manual, this paper, a github site (confirmed by my own traces) and the following ADEPT hack.

In the simplest ADEPT setup, there are three parties involved. A user running Adobe Digital Editions (ADE, currently at version 1.7), a distributor running Adobe Content Server (ACS, currently at version 4), and Adobe itself (!).

In ADEPT, ebooks are encrypted with a book key (i.e. each digital copy of the same book is encrypted with the same key). The distributor picks this key, and encrypts the ebook using that key.

Each user has his own user key. This key is generated when the user installs Adobe Digital Editions (ADE), and is uploaded to Adobe. Users are encouraged to activate their copy of ADE using an Adobe ID. Different devices (at most 6) may be activated using the same Adobe ID. Each of these devices then use the same user key (and hence can process any license issued to this key, allowing a single ebook to be read on multiple devices). It seems that each time ADE is started, it fetches this key from Adobe (this would make sense, because then the user key is never stored on disc making it harder to obtain it).

When a user buys an ebook, two things happen: ADE downloads the encrypted ebook from the distributor, and ADE obtains a license for this ebook through a process called fulfillment. The fulfillment proces runs as follows.

First ADE authenticates to the distributor (in fact it only identifies itself by sending three certificates and the user id). Then ADE contacts adeactivate.adobe.com with a LicenseServiceRequest that contains again the user id, a nonce, and a signature. It is unclear to me what the purpose of this step is (it is also not described in the message flow in the Adobe Content Server User Manual).

Then ADE sends a fulfillment token (basically an unsigned license containing the user id and information about the ebook bought) to the distributor. This message is signed (presumably by the user key). The distributor forwards the unsigned license to Adobe. Either Adobe or the distributor include the book key, encrypted against the user key. The resulting license token is signed by Adobe and sent through the distributor back to the user. This license is stored with the encrypted ebook. Because it contains the book key (encrypted against the user key) it allows ADE to decrypt the ebook whenever the user wants to read it.

Because the unsigned license sent to Adobe contains both the user id and information about the book, Adobe gets to know all the ebooks you buy. This is a clear privacy infringement. It is also unnecessary.

I don't think Adobe needs to sign licenses directly. Why can't the distributor sign the license certificate himself, with a key certified by Adobe (for which the distributor can provide the Adobe issued certificate to the user application). If a check needs to be made against the user, only the user id (not the details about the book bought) could be sent to Adobe for a 'background check'. It would reveal to Adobe how many books you buy, but at least not which ones.

I have compiled this post based on the limited information I could find. Any more information would be appreciated.