These days, security is being built into embedded
applications at all levels, including the hardware. However,
the wide range of encryption applications, standards,
and protocols makes it difficult at best to create a universal
platform. The tables on common encryption standards
(Table 1) and common encrypted protocols (Table
2) give just a clue of the options available.
Hardware can address a host of security issues. For
example, AES (Advanced Encryption Standard) encryption
acceleration in Rabbit Semiconductor’s Rabbit
4000 can be used with an SSL stack. It speeds the
process, but it only provides security for data being
transmitted between the 8-bit microcontroller and
another network device. It does not guarantee that the
information is correct or from a particular source, only
that it will move from point A to point B without being
tampered with or viewed.
SSL/TLS provides endpoint authentication and encryption,
but improper configurations can be susceptible to
things like man-in-the-middle attack. Improper use of
security software and hardware is the main reason developers
need to be aware of its use as well as misuse.
Simply putting something in hardware does not mean
an approach will be useful in the long run. The SDMI
(Secure Digital Music Initiative), a digital rights management
(DRM) scheme, used a hardware-based key system
to implement a digital watermarking scheme. SDMI was
flawed and has since disappeared into the archives of
the Internet. It is on par with the Content Scrambling System
(CSS) used with DVD movies.
Securing the base
SDMI started from the right
point with a unique, unalterable key. But normally, this
must be surrounded by
more hardware to prevent
tampering. For many systems
where physical security
is not an issue, platforms
such as the Trusted Computing
Group’s TPM (Trusted
Platform Module) can
provide the basis for a
secure system.
Initially implemented as
separate and secure chips,
many TPMs were incorporated
into PC motherboards
such as IBM laptops. VIA
Technologies implemented
a version called Padlock
that adds features like AES
encryption. These types of platforms can support operating-
system features such as Vista’s BitLocker, an encrypting
file system.
Zilog’s 32-bit ARM922T-based Zatara microcontroller
highlights most of the options required for securing a
microcontroller, including a secure boot ROM and tamperdetection
support (Fig. 1). In particular, there is a 40-kbyte
secure RAM that will be zeroed if the tamper-detection circuits
are attacked.
Tamper detection is not new. But it is becoming more
common and moving up the food chain to larger processors.
Most 64-bit processors are mated with external
hardware to address this problem, as with a TPM. Yet
securing a system from the inside out is critical to a fully
secure system.
Still, a system that takes security to extremes may only
be required in certain circumstances such as controlling
a nuclear reactor or managing large cash transfers. In
these cases, the added cost and complexity of the controlling
microprocessors are less of an issue.
The softer side of security
Software is critical
to system security regardless of the base it starts
from. Obviously, running secure code from the start is an
issue that is best addressed by a hardware solution. But
once running, a system needs additional secure software
to manage system security.
General Software’s Embedded BIOS with StrongFrame
is one way to address the underlying software aspects of
a system. Its Boot Security Application is a firmware application
that establishes trust between the hardware and
applications. It was designed to prevent the operation of
a system that has been compromised by the unauthorized tampering with the BIOS, operating
system, or application. It uses
digital signatures to track trusted
objects. The 20-kbyte module can be
compressed by 50% in ROM. The system
can be extended using Firmbase
Technology’s Trusted Computing
Base (TCB), which supports plug-in
Security Authorities allowing custom
authentication and authorization.
General Software’s approach targets
a range of standard processor
architectures and operating systems,
while Freescale’s Mocana
Device Security Framework is targeted
at Freescale processors such
as the PowerQUICC series. The PowerQUICC
has had an encryption
engine almost since its inception
because its targets include routers
and gateways that provide virtual
private network (VPN) support.
Hardware encryption significantly
improves the throughput of secure
information.
Mocana has a range of software
products like its Embedded Security
Suite. But the Mocana Device Security
Framework modules for Freescale
processors are designed to integrate
this software with the PowerQUICC
security engine so developers don’t
have to deal with the hardware
directly. Modules include support for
SSL Server, SSL Client, SSH Server,
SSH Client, IPsec/IKEv1 and IKEv2,
and Certificate Management Client.
Designed for open standards, the
system is RFC-compliant and multicore-
friendly.
Continued on page 2.