Developing Effective Design Strategies for

Todays Wearable Devices:

SECURITY
(Paper #3 of a 3-part series)

W H I T E P A P E R

WARREN KURISU
DIRECTOR OF PRODUCT MANAGEMENT

w w w.m e n t o r.c o m

Wearables: Security

This series of white papers, presented by Mentor Graphics, has been created to assist system architects and software
developers who design embedded systems for wearables. The first paper, Developing Effective Design Strategies for
Todays Wearable Devices: Key Factors Driving the Market, touched on the market forces and the growth segments
within the wearables industry. This second paper, Power Management, discussed techniques for power management
including how a multicore framework can assist software developers. This final paper in this series, Security covers
security issues and explains how developers can use technologies and techniques available today to ensure secure
wearable device operation.

SECURITY FOR WEARABLES

It seems with each passing day we hear of a new data breach somewhere in the world. The malicious attacks can
come from individuals, groups, or even from some type of clandestine government operation. As end users rely
more on their connected devices, and businesses throughout the world transition to online activity, these
nefarious actions of cyber-attack must be stopped. And while a 100 percent secure wearable on a network is
nearly impossible, software developers and architects can still do their part to minimize the chances of a cyber
data breach. Many of the precautions required are readily available today. In some cases, its the mindset around
designing for security that needs to be addressed. Essentially, security can no longer be thought of as an after
thought to embedded system design. Security needs to be considered from the first day a concept begins. Also,
building security into a design must be thought of as protection against a design, an investment, rather than a
cost nobody cares to cover.
Because so many wearable devices connect to dispersed public networks and support bi-directional data flow,
most devices are highly susceptible to attack. Just look at the diverse set of network connectivity options available
today compared to 20 years ago; Wi-Fi, ZigBee, Bluetooth, and 4G cellular simply did not exist. Each connectivity
option has very clear advantages as well as disadvantages when it comes to secure communications.
Without designing in security methods to address the full of range of threats, wearables are vulnerable to attacks
from even the most unsophisticated malcontent . Without question, active and passive threats have to be detected,
neutralized, and corrected before any harm to the individual device occurs. To ensure security, development teams
should adopt a security development lifecycle approach that meets their requirements. For example, Microsoft has
developed a comprehensive Security Development Lifecycle process that companies can use as a starting point
(www.microsoft.com/en-us/sdl/).
Clearly, security is a very broad topic that begins with device conception and spans planning, process, activities,
and technology. The remainder of this paper focuses on a handful of key technology topics that are useful, if not
critical, to building secure wearable devices. These topics include:
The use of Public Key Infrastructure (PKI) for boot-time authentication and code authentication
Establishing a chain of trust to ensure downloaded code and data are authenticated and validated
Process separation using MMU-based memory protection to partition critical code and memory spaces
Leveraging safety-certified code
Hardware enforced system partitioning with ARMTrustZone
Lets take a closer look at some of the techniques and technologies software developers are using to build security
into their wearable devices.

w w w. m e nto r. co m

Wearables: Security

CODE AUTHENTICATION/BOOT-TIME AUTHENTICATION

Code authentication is essentially binary OS image authentication. Developers can set up their system to check
to see if data coming in originated from the original equipment manufacturer (OEM). Further, as the developer,
you need to investigate whether any of the code has been modified. Code authentication (Figure 1) and secureboot authentication (Figure 2) are some of the most basic steps developers can take to secure their embedded
wearable system.

Figure 1: Code authentication requires the use of both

a Public Key and a Private Key. The Public Key is made
available to everyone on the network via a publicly
accessible repository or directory. On the other hand,
the Private Key must remain confidential to its respective
owner. Because the key pair is mathematically related,
whatever is encrypted with a Public Key may only be
decrypted by its corresponding Private Key and vice
versa. This type of authentication achieves a high
level of confidentiality.

Figure 2: Secure-boot authentication starts by executing

a first stage boot loader stored within secure flash memory
provided by the Trusted Platform Module (TPM) hardware.
This boot loader is stored within protected memory so it
cannot be replaced by hackers. Also stored in protected
memory is the signature and crypto key for the second
stage boot loader. The first stage boot loader calculates
the signature of the second stage boot loader using the
hardware crypto support and crypto key. If the calculated
signature for the second stage boot loader matches the
stored signature, we know the second stage boot loader
is valid and allowed to run. The second stage boot loader
repeats this verification process before loading the
operating system.

w w w. m e nto r. co m

Wearables: Security

ESTABLISHING A CHAIN OF TRUST

Once the initial boot stage has been confirmed, the process can continue to create a chain of trust. By using the
same Public/Private key approach, subsequent executable modules can be downloaded, verified, loaded, and run
(Figure 3). This approach becomes particularly interesting in the case of a complex wearable device, that might be
loading different operating environments and applications depending on the functional requirements required at
any given time.

Figure 3: Chain of Trust When we build our wearable device, we want it to be trustworthy and we want the software that runs
on it to be authentic. To accomplish this, we establish a software chain of trust which starts from the root, the hardware. The process
begins at the authentication step to make sure the hardware authenticates the boot ROM, the boot ROM authenticates operating
systems, and then, of course, the operating systems authenticate the application layer. The goal of this strategy is to prevent applications
from executing that havent been signed and authenticated. When we have the system up and running, we can prevent attacks and
uploading of malicious code by looking at every file that is being downloaded, making sure that its signed and authenticated.

PROCESS SEPARATION
The introduction of new SoCs designed for wearables provides enhanced system performance capable of running robust applications. However, the need to reduce size, power consumption, and cost will challenge software
developers to run complex applications with limited memory resources. And this is where process separation can
best be used. And while process separation leveraging a system MMU or MPU does not guarantee security, it does
help to contain misbehaving applications from affecting other process applications or the kernel itself.
Nucleus Process Model (Figure 4) is a light-weight approach for space partitioning that creates protected
memory regions offering full isolation of kernel and middleware resources. In this manner, scribblers, stack
overflows, accessing rogue pointers, etc., in application code can no longer corrupt or interfere with system
software operation. Utilizing the MMU or MPU, Nucleus Process Model partitions memory to create protected
memory regions without virtualizing memory which is extremely important with wearables. Space partitioning
provides the framework to load new applications using cloud services, or the ability to partition large algorithms
into smaller components that are loaded slightly ahead of execution time. With Nucleus Process Model, manufacturers of wearables have the ability to provide compelling applications on devices with limited system
resources with a level of security built in.
Nucleus can also take advantage of advanced hardware-based security separation mechanisms to enable a Secure
Execution Environment (SEE) which ensures data and code loaded within that secure partition can be completely
isolated from the rest of the system. SEE is discussed later in the paper.

w w w. m e nto r. co m

Wearables: Security

Figure 4: Nucleus Process Model adds task and library isolation as well as memory protection to a real-time
embedded platform either on an MMU or MPU.

NUCLEUS SAFETYCERT
Mentor Embedded Nucleus SafetyCert (Figure 5) is a safety-certified real-time operating system (RTOS) and
middleware package targeting high-performance, next-generation applications. Nucleus SafetyCert is designed to
meet the stringent safety and regulatory requirements for embedded devices, including system architectures that
leverage the hardware MMU/MPU for process separation. As with using a process model, running a safety-certified
operating system by itself does not guarantee security. However, by building on a safety-certified foundation,
developers have an additional level of confidence that the code will behave as intended, which improves system
reliability. Safety-certified environments also help avoid situations that might result from software faults that could
cascade across the system
and result in security vulnerabilities in unrelated sections
of code.
Nucleus SafetyCert allows
developers to shorten the
path to regulatory certification
with a complete certified
solution that includes all the
necessary documentation and
artifacts required for users to
develop mission critical
Figure 5: Nucleus SafetyCert commercial solution addresses a broad
range of IoT sectors and includes a
full spectrum of development tools
(quality processes with test and
documentation) available to Nucleus
embedded software developers.

w w w. m e nto r. co m

Wearables: Security

applications. Nucleus SafetyCert has been documented to meet the certification requirements for wearables
or medical devices requiring International Electrotechnical Commission (IEC) standard 62304 certification.

SECURITY THROUGH ARM TRUSTZONE

ARM TrustZone architecture (Figures 6 & 7) provides a solution that carves out or segregates a hardware subset
of the SoC. It does this by defining processors, peripherals, memory addresses, and even areas of L2 cache to run
as secure or non-secure hardware. A SoC that utilizes ARM TrustZone technology has the ability to dynamically,
with only a few clock cycles delay, transition a system into secure world processing, where a subset of the hardware is
partitioned, and data and processing is completely invisible to the rest of the system.
The normal world (or non-secure world) created and enforced by the ARM TrustZone can be used to define a
hardware subset of the SoC. ARM TrustZone ensures that non-secure processing can access only non-secure
resources and receive only non-secure interrupts. For example, a normal world hardware subset might include the
UART and USB interface, but exclude
Ethernet access. The Ethernet might
instead be dedicated to the secure world
where a separate RTOS or application runs
for the sole purpose of managing all
Ethernet traffic, independent of the
normal world software stack.

Figure 6: The ARM TrustZone is well-suited for single-core configurations.

Mentor Embedded Multicore Framework (MEMF) plays a key role in such a
scenario.

Figure 7: The ARM TrustZone is also well-suited for multicore architectures. Again,
Mentor Embedded Multicore Framework plays a central role here.

w w w. m e nto r. co m

Software that runs in the normal world

is assumed to be flawed from a safety
and security perspective. That is, normal
world software is expected to contain
bugs, exploits, hacks, faults, or irregularities that could expose sensitive information or functions. It is these assumptions
that drive the value of ARM TrustZones
ability to isolate the adjacent processing
area (secure world) where sensitive data
storage or functions are managed from
the perceived flawed normal world
software.
Unlike the hardware subset in which
normal world software runs, software
running within the secure world has
complete access to all of the SoC hardware. Thus, from the perspective of the
secure softwares execution, the system
looks and acts nearly identical to what
would be seen on a processor that does
not have ARM TrustZone. This means
that secure software has access to all
resources associated with both the
secure and normal worlds.
ARM TrustZone architecture contributes to
the overall system security by preventing
normal world software from accessing the

Wearables: Security

secure world resources. It is important to understand that ARM TrustZone does little to improve the safety or
security of the software that runs in the secure world except to prevent unwanted secure world access by normal
world software. It goes without saying that for the secure world to be completely trusted, the system must
initially boot in a trusted state (see the earlier discussion about trusted boot). Beyond that, it is the developer who
determines which software is trusted typically through rigorous development processes, testing, certification, and
supporting a chain of trust strategy in the secure world.

CONCLUSION
Security for wearables is a complex subject. While designing an embedded system from the ground up provides
many of the proven security capabilities other electronic system designs have been using for years secure boot,
code authentication, and chain of trust to name a few these are basic fundamental security capabilities that every
wearable needs to include today (when applicable). This paper described how Mentor Graphics is dedicated
to assisting developers when building security into their embedded wearable systems. Mentors involvement
in building for certification using Nucleus RTOS and involvement in secure execution environments with Mentors
multicore framework capability are opening new doors for developers.
To view white paper #1 (Factors Driving the Market) and #2 (Power Management) in this 3-part series, please visit
the Mentor Embedded Systems website.

Authors biography
Warren Kurisu is the Director of Product Management in the Mentor Graphics Embedded Systems Division,
overseeing the embedded runtime platform business for the Nucleus RTOS, Mentor Embedded Linux,
virtualization and multicore technologies, safety certified runtimes, graphics and development tools. Warren
has spent nearly 30 years in the embedded industry, both as an embedded developer and as a business
executive, working broadly in industries including aerospace, networking, industrial, medical, automotive,
and consumer. Warren holds a masters degree in Electrical Engineering from the University of Southern
California and a Master of Business Administration from the University of California at Berkeley.

The registered trademark Linux is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a
worldwide basis.

For the latest product information, call us or visit:

w w w . m e n t o r . c o m

2016 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may
be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 02-16 TECH13950-w