It is very easy to see logically why in order to create a truly secure protection
technology there must be a secure trusted component in the system that is
responsible for enforcing the protection. Modern computers are “open” in the
sense that software runs on the CPU unchecked—the CPU has no idea what
“rights”a program has. This means that as long as a program can run on the
CPU a cracker can obtain that program’s code, because the CPU wasn’t
designed to prevent anyone from gaining access to currently running code.
The closest thing to “authorized code” functionality in existing CPUs is the
privileged/nonprivileged execution modes, which are typically used for iso-
lating the operating system kernel from programs. It is theoretically possible
to implement a powerful copy protection by counting on this separation (see
Strategies to Combat Software Piracyby Jayadeve Misra [Misra]), but in reality
the kernels of most modern operating systems are completely accessible to end
users. The problem is that operating systems must allow users to load kernel-
level software components because most device drivers run as kernel-level
software. Rejecting any kind of kernel-level component installation would
block the user from installing any kind of hardware device on the system—
that isn’t acceptable. On the other hand, if you allow users to install kernel-
level components, there is nothing to prevent a cracker from installing a
kernel-level debugger such as SoftICE and using it to observe and modify the
kernel-level components of the system.
Make no mistake: the open architecture of today’s personal computers makes it
impossible to create an uncrackable copy protection technology. It has been
demonstrated that with significant architectural changes to the hardware it
becomes possible to create protection technologies that cannot be cracked at
the software level, but even then hardware-level attacks remain possible.
Class Breaks
One of the biggest problems inherent in practically every copy protection tech-
nology out there is that they’re all susceptible to class breaks(see Applied Cryp-
tography, second edition by Bruce Schneier [Schneier1]. A class break takes
place when a security technology or product fails in a way that affects every
user of that technology or product, and not just the specific system that is
under attack. Class breaks are problematic because they can spread out very
quickly—a single individual finds a security flaw in some product, publishes
details regarding the security flaw, and every other user of that technology is
also affected. In the context of copy protection technologies, that’s pretty much
always the case.
312 Chapter 9