Quote:
Originally Posted by rkomar
If the key is obtained over the net in a secure manner each time the book is opened, then it gets harder for the user to get their hands on it. It also makes the key book-specific and possibly random (rather than having the same, guessable key for the entire library).
|
There's no such thing as transmitting data in a secure manner when the code is running on a general-purpose computer. The way most folks attack DRM is to first run the app in a debugger, then at such a point as you believe the key exists in memory, dump the contents of the app's address space, throw away everything of known origin (the app binary itself, libraries, frameworks, and the contents of the book), and then go through the remaining data looking for a blob of data large enough to be a key.
With the scheme you propose, however, it is even easier to obtain the key data. If you know that the key is coming in over a network, you can trivially patch the operating system's crypto routines to write a copy of the unencrypted data to a file on disk. Or if the app just uses stock HTTPS encryption, you could use the Charles Web Debugging Proxy, and skip all the hacking entirely.
Besides, your readers will march on your HQ with torches and pitchforks if you actually implement always-on DRM; just look at what happened when the game industry tried it.
Basically, the DRM problem is the same as the "How do I securely communicate with a server using a public terminal that might have a keylogger installed" problem. The answer is, "You can't." If you can't trust the endpoint, then security is fundamentally compromised, and there's nothing that anyone can do to change that reality. Anything you might implement to work around such a compromised terminal can be defeated by a sufficiently clever attacker, resulting in an infinite cat-and-mouse game that just costs a lot of money for no useful benefit in the long run.