DRM doesn't provide security
DRM is
important to many and a bane for most, but it tends to be
inextricably linked to hardware-based security and encryption.
The dependency on hardware support is in part
based on the need for end-to-end protection of content
and the required throughput of a system. For example,
encryption/decryption of streaming audio or video must
occur at line speeds or playback quality will suffer.
Consumer demand seems to be pushing DRM out of the
audio space, but it remains critical on the video side. Highbandwidth
Digital Content Protection (HDCP) protects some
HDTV content today, and it is
built into the source and destination
of HDTV devices including
Blu-ray and HDTV drives.
Luckily, transport of data
between devices is assumed to
be in the clear, so it does not
involve any encryption or protection.
In general, only devices
created as endpoints need to
address this type of DRM.
On the other hand, protecting
the object code of an application
is often desirable. This may
require encryption if the code is coming from a non-secure, offchip
site such as a flash memory chip. In this case, the processor
would have to decrypt the code as it is executed. This isn’t
common, but several microcontrollers can perform this function,
such as the 8051-based DS5250 from Maxim-IC.
Another approach is to have a boot loader that can decrypt
off-chip code into an on-chip RAM and then execute from
RAM. The decrypted code is lost when power is removed.
The typical alternative is to use an on-chip code protection
scheme that typically prevents the flash memory from being
read by the usual debugging means. It usually prevents programming of the flash without an additional key. Otherwise,
a rogue application could be loaded in a small part of the
memory. The application could then download the remainder
of the intact code to an attacker.
Multilevel security
Controlling code and
access to code is typically part of a microcontroller’s memory
and system protection system. Highly secure systems
typically combined this with options such as secure boot
and secure storage to bring up a secure
operating system such as SE Linux (Security
Enhanced Linux) from the NSA (National
Security Agency). A further extension is
support for virtual machines.
With the exception of the secure boot
and secure storage, encryption isn’t necessarily
part of the systems’ security. Instead,
standard microcontroller virtual memory
and virtual-machine support is sufficient to
implement multilevel security (MLS). Additional
hardware features can be incorporated
into a system, but these are rarely found
on standard microcontrollers.
The reason developers need to know
about these aspects of security is that
they do not require additional hardware, but the software
does make certain assumptions about the starting point
of the system, such as the boot process and the operating
system. Systems that fail to meet these assumptions
can be compromised often without resorting to any
decryption. Unfortunately, these aspects of security are
beyond this article, so do not assume that simply including
hardware encryption or even secure boot features will
provide a secure system.