Quote:
Originally Posted by rkomar
If you read my comments earlier, you'd see that I'm more interested in the impact on those of us who want to rid their own purchased ebooks of DRM encryption. I don't care about how easy it is for professional pirates. I don't think that most people who own an encrypted book are interested in getting it from the darknets either. We already paid money for it.
|
The problem is, most people will then rid their own purchased eBooks of DRM by downloading a cracked copy from somewhere, and if someone accuses them of copyright violation, they'll trot out their purchased copy as proof that they do have a license for the content. Whether that will hold up in court is anybody's guess, but at least ethically, they'll be in the right to do so.
The bigger problem with that is that the strength of the DRM then draws people to illegal download sites, which makes them statistically more likely to download pirated content that they
don't legally own. Thus, even hypothetically near-perfect DRM tends to encourage piracy rather than diminish it, and diminish sales rather than increase it.
Quote:
|
Finally, if the decryption is done within the Trusted Execution Environment itself (rather than just the key store being decrypted there), then no part of the decryption takes place in the "normal world" reading app. So, the warez binary you will be left with won't decrypt anything.
|
Ah. You're talking about running the entire book reading app inside the TEE. There's little question about whether that scheme would eventually be cracked, though it would be more difficult.
One possible attack involves debuggers. After all, the folks developing the software have to have a way to debug it, which means there's almost guaranteed to be some means of attaching some sort of debugger to gain access to those protected tools' memory, even if it requires soldering JTAG pins somewhere.
Another possible attack involves modified CPUs with dual-ported RAM and a second core that sniffs the main RAM. It is likely impossible to close that hole.
A third possible attack involves attacking the TEE itself. The purpose of a TEE is to run very simple, minimal software that is robust against attack, for very limited purposes, such as protecting device passcodes and biometrics data. The more complicated the software you run in the TEE, the more impossible it becomes to secure it. Because the entire book reader would run in the TEE, chances are good that any security holes in the main OS would also exist in the TEE, because you'd be importing most of the code. Thus, at that point, your TEE would be no more secure than the rest of the OS, so you'd have people doing all sorts of attacks on it through the content itself, looking for buffer overflows in image parsers, etc.
This, of course, assumes that they would even bother to attack the TEE in the first place, rather than going around it entirely. After all, most consumers demand to have access to their content on computers (even if they don't prefer to consume it there), and DRM is only as secure as the weakest system on which the content is accessible.