Threat-based Analysis Method

for IoT Devices

Jack Ogawa, Senior Director, Marketing, Microcontroller Business Unit, Cypress Semiconductor Corp.
Berenice Mann, Senior Marketer, Architecture and Technology Group, Arm

Introduction
By all accounts, Internet of Things (IoT) devices are forecasted to become ubiquitous. These devices, powered by semiconductors,
will make every imaginable process smart. From simply turning on a light to more complex processes such as outpatient care or
factory control, IoT devices utilizing sensing, processing, and cloud connectivity will dramatically improve their ef ciency. The
applications are diverse, and their promise and impact are unbounded.

However, the growing “smartness” of connected devices introduces security challenges. For example, traditional lighting control is
relatively primitive – it’s a power circuit with a physical switch. Operating the switch requires physical proximity. Securing this
process against unauthorized use simply requires physical protection of the switch. Now consider lighting control in its smart
incarnation as an IoT device. The physical switch is replaced by light and proximity sensors, logic (typically implemented in a
microcontroller), and wireless connectivity to a cloud-based application. In becoming smart, a light switch is transformed into an
embedded client that works with an application server through a network. Securing the smart light switch has become much more
complicated. This added complexity will present challenges to all IoT device designers. The good news is that secure
microcontrollers can greatly enhance the security of the IoT device and accelerate the design cycle.

This paper offers a case study to determine the security requirements of a network-camera IoT device. This device is, by de nition,
already connected and is used widely in a number of applications, from cheap home web-cams to complex industry systems. By
de ning the relevant threats against the network camera and determining the security objectives to defend against those threats,
the security requirements for the device will be established. It presents Cypress’ PSoC® 6 MCU, based on Arm® technology, as a
solution that meets these requirements. The methodology can be applied to other IoT devices as well.

IoT Device Security Analysis

The idea of securing IoT devices can be daunting. Initial research immediately reveals large bodies of knowledge regarding
cryptography, threats, security objectives, and several other topics. Faced with overwhelming information, often the rst question
that IoT device designers ask is, “How do I judge how much security I need,” closely followed by “Where do I start.”

Arm offers the Platform Security Architecture (PSA) to help designers get started. By utilizing PSA’s holistic set of threat models
and security analyses, hardware and rmware architecture speci cations, and Trusted Firmware-M reference implementation, IoT
designers can quickly and easily implement secure designs.

Cypress’ PSoC 6 MCUs achieve the highest-level of protection de ned by the PSA through the use of dual Arm Cortex®-M cores,
combined with con gurable memory and peripheral protection units. This paper takes the PSA Network Camera Threat Model and
Security Analysis (TMSA) and applies it to PSoC 6 MCUs to demonstrate how to assess a network camera application for security.
The objective of any attack is to gain access to an IoT device’s data and somehow exploit it. Figure 1 shows that the rst step in
the analysis process is to identify data assets handled by the IoT device and their security properties.

!
Identify Data Assets Identify Threats Define Security Objectives Requirements

Figure 1. Analysis process for designing secure IoT devices

The next steps are to identify threats that target these assets, de ne security objectives to resist these threats, and decide on the
requirements to satisfy the security objectives. By meeting these requirements, a microcontroller-based design supports the
security objectives and ultimately preserves the security properties of the assets. Finally, the design should be evaluated to
determine if it achieves the objectives. Typically, this evaluation utilizes threat models applied to the design to assess the attack
resistance of the device.

Data Assets
The value of every IoT device is built on data, and how that data is managed. Data assets take various forms in an embedded
system. For example, rmware de nes the behavior of the device. Other examples include unique ID, passwords, and encryption
keys that are used to control the device. Also, there is the data generated by the IoT device, such as image data from a webcam, or
environmental data from sensors. Regardless of its form, each data asset has security properties. Security properties are inherent
characteristics of the data asset that the system relies on as the basis of trusting that data asset. There are three security
properties: con dentiality, integrity, and authenticity.

Confidentiality
/känfədenSHēˈalədē/ noun: the state of keeping or being kept secret or private.
Con dentiality requires that only authorized people can read the data asset. In other words, it is kept secret or private.
Passwords are a common example of a data asset with a con dentiality security property. Others might be personal data
generated by the IoT device, such as heart rate or perhaps location.

Integrity
/inˈteɡrədē/ noun: the state of being whole and undivided
Integrity requires that a data asset remains unchanged through its use or transferal. Integrity is typically associated with data
that establishes a reference, such as boot rmware. Boot rmware ensures that the MCU con gures to a known initial state from
which applications can execute. Changes to the boot rmware can affect this initial state and present an operational or security
risk.

Authenticity
/ˌôTHenˈtisədē/ noun: the quality of being authentic (of undisputed origin; not a copy; genuine)

Authenticity requires that only a trusted actor has established the current state of a data asset. When combined with integrity,
authenticity establishes trust, and therefore it is a critical cornerstone of a secure IoT device. In the prior boot rmware example,
a digital signature can be used to evaluate authenticity and integrity when upgrading rmware to ensure that only trusted
rmware is used.

It is critical to comprehensively identify data assets in the IoT device, since each subsequent step relies on this step. To
illustrate, a web camera will have the following data assets:

Camera ID A unique identi er for the device

Firmware De nes how the hardware operates
Firmware Credentials Used for secure boot
Credentials Data used for cryptographic operations
Logs Historic data
Images Data captured by the camera and sent over the network
Configuration Data used for con guration, including network con guration
Each data asset will have security properties associated with it.

Data Asset Secure Properties

Camera ID Integrity
Firmware Con dentiality (optional), Integrity, Authenticity
Firmware Credentials Integrity
Credentials Con dentiality, Integrity
Logs Integrity
Images Con dentiality, Integrity
Configuration Con dentiality (optional), Integrity
Threats
The objective of a threat is to compromise the security properties of a data asset and utilize it for unauthorized purposes. To
identify threats, the use of the data asset in the IoT device must be evaluated. For example, credentials might be used to gain
access to an IoT device’s network. If the con dentiality of credentials is compromised, then they can be used by unauthorized
actors to gain access to the network. This type of attack is called impersonation. By methodically evaluating each data asset, a list
of potential threats can be created.

Continuing with the illustration, a web camera may face the following threats against its data assets:

Threat Targeted Data Asset Security Properties

Impersonation Credentials Con dentiality, Integrity

Man in the Middle Credentials
Images
Con guration Con dentiality, Integrity
Con dentiality Integrity, Con dentiality, Integrity

Firmware Abuse Firmware Con dentiality, Integrity, Authenticity Tamper Camera ID Integrity
Firmware Con dentiality, Integrity
Firmware Authenticity
Credentials Integrity
Credentials Con dentiality, Integrity
Logs Integrity
Images Con dentiality, Integrity
Con guration Con dentiality, Integrity

Security Objectives
With threats identi ed, security objectives can now be de ned. Security objectives are de ned at an application level, in essence
providing implementation requirements. Some security objectives can be implemented as Trusted Applications (TAs) that execute
in an isolated execution environment provided by the secure MCU. The isolated execution environment comprehensively protects
the TAs and the data that they use/process. The IoT device application itself operates in an unsecure execution environment and
communicates with TAs in the isolated execution environment through an API that uses an inter-processor communication (IPC)
channel. The TAs in turn utilize the resources available (such as crypto accelerators and secure memory) in the hardware to
support the objective.
Continuing with the example, the threats identi ed previously can be countered by the following security objectives:

Threats

s
n

r
o
r

a
s

m
p
t

i
r

I M F T

Security Objectives Firmware Authenticity XX X

Access Control
Communication X
Secure Storage XX
Secure State
X
Access Control: The IoT device authenticates all actors (human or machine) attempting to access data assets. Prevents
unauthorized access to data assets. Counters spoo ng and malware threats where the attacker modi es rmware or installs an
outdated awed version.
Secure Storage: The IoT device maintains con dentiality (as required) and integrity of data assets. Counters tamper threats.
Firmware Authenticity: The IoT device veri es rmware authenticity prior to boot and prior to upgrade. Counters malware threats.

Communication: The IoT device authenticates remote servers and provides con dentiality (as required) and maintains integrity of
exchanged data. Counters Man in the Middle (MitM) threats.
Secure State: Ensures that the device maintains a secure state even in case of failure of veri cation of rmware integrity and
authenticity. Counters malware and tamper threats.

Requirements
At this point, the analysis provides a logically connected model of data assets, threats, and security objectives. From this
picture, a list of required capabilities or features for a secure MCU can be compiled. This list can of course then be used as
solution implementation criteria for the particular IoT device application.

Lifecycle matters
Note that the requirements for a security objective may change according to the lifecycle stage (design, manufacturing,
inventory, end use, and termination) of the IoT device and should be considered as well.

The analysis of the example now can be presented:

Each data asset will have security properties associated with it:

Security Objective Targeted Data Assets 2 Use Term

Properties Design Mfg Inventory End
Countered Threats Security
Access Control1 Tamper Data I N/A eFuse eFuse eFuse eFuse Dead4
Con guration T. Con guration I, A C, I C Dig Sign N/A Dig Sign N/A Dig Sign N/A Dig Sign Dead4 Dead4
Secure Storage1 Firmware
Keys C, I N/A N/A N/A Encryption Dead4
Spoo ng
C N/A N/A SEF3 SEF3 Encryption SEF3
Malware HW ID
Dig Sign N/A N/A Encryption Dig Dead4 Dead4
T. Firmware UserI, A
Dig Sign N/A Sign
Firmware Auth Malware T. Firmware I, A Dig Sign Dig Sign Dig Sign Dig Sign Dead4
Comm1 MitM User C, I C, I N/A N/A N/A SEF3 N/A SEF3 Encryption SEF3 Dead4 Dead4
Data Keys
Secure State T. Firmware User I Dig Sign N/A Dig Sign N/A Dig Sign Dig Sign eFuse Encryption SEF3
Malware Tamper Data I, A I, A C, I C N/A N/A Encryption Dig Sign Dead4 eFuse Dead4
T. Firmware HW ID Con guration Keys C, I N/A SEF3 Encryption SEF3 Encryption Dead4 Dead4 Dead4
Dig Sign N/A Dig Sign eFuse Dig Sign eFuse
Notes:
1. Ideally implemented as a TA in an isolated execution environment
2. C = Con dentiality, I = Integrity, A = Authenticity
3. SEF = Secure Element Functionality
4. Dead = Secure MCU in a non-operational state

Choosing the right MCU

Through analysis, a summary of the required security capabilities of the MCU required is presented:

Isolated execution environment for trusted applications: While the preceding analysis has focused on secure data assets, every IoT
device also has unsecure tasks/applications with unsecured data assets. The MCU should provide a strong method of keeping
unsecure and secure processing isolated. The concept is similar to an airport: the boarding areas are secured and isolated. Only
authenticated individuals are allowed to do things (e.g. board) in the secure area. It is important for the MCU to offer strong,
hardware-based isolation between unsecure and secure execution environments.

Secure element functionality: Within the isolated execution environment, further isolation is needed to store data assets such as
encryption keys that are foundational to security. Continuing with the airport analogy, each passenger maintains secure possession
of their credentials. MCUs must provide further isolation for root of trust storage and associated secure services.

Encryption: MCUs with dedicated hardware accelerator blocks with controlled access are preferred. Accelerator blocks help with
performance. Access control (isolation) of the blocks protects against access by unauthorized programs, ensuring that encryption
keys remain in a secured environment.
Digital signature: The authenticity and integrity of data assets can be assessed by using digital signature algorithms such as
ECDSA and RSA. MCU rmware is the most-apparent use case of digital signatures. The MCU should provide hardware-based
support of hash and signing to evaluate rmware images prior to loading.

eFuses: Immutable data assets are important for securing a design. They are typically used as references for system behavior.
Typical examples are lifecycle designation, unique identi cation numbers (UID), manufacturer numbers, and other references that
persist through the life of IoT device.

Conclusion
This paper presents an analysis method for determining the requirements of a secure IoT device. By creating a logically
connected model of data assets, threats against these assets, and security objectives to counter the threats, a list of
requirements can be derived that can be used as criteria for implementation solutions.

The vast majority of IoT devices will be built upon MCU-based embedded systems. This growth opportunity is attracting a new
breed of MCUs that offer security features and capabilities to maintain the security properties of data assets. Cypress’ PsoC 6
secure MCUs are one of the rst of such new MCUs. The PSoC 6 MCU architecture was designed for IoT device applications,
offering ultra-low power for extended battery life, ef cient processing capacity, and hardware-based security features that support
security objectives:

Isolated execution environment: PSoC 6 secure MCUs isolate secure operations from unsecure operations through the use of
hardware isolation technology:
• Con gurable protection units are used to isolate memory, cryptography, and peripherals
• Inter-Processor Communication (IPC) channels between the Arm Cortex-M4 and Cortex-M0+ cores are provided to support
isolated API-based interaction
• Ideal for implementing Trusted Applications that support the security objective of an IoT device

Integrated secure element functionality: The hardware isolation technology in PSoC 6 supports isolated key storage and crypto
operations, delivering secure element functionality in addition to the isolated execution environment. • Ideal for secure key storage
• Supports a pre-installed root of trust to anchor secure boot with a chain of trust

Isolated, hardware-accelerated cryptographic operations: Includes AES, 3DES, RSA, ECC, SHA-256 and SHA-512, and True
Random Number Generator (TNRG).

Lifecycle management: eFuse-based lifecycle management capability ensures secure behavior in the event of security errors
such as rmware hash check failures.
Rich Execution Environment Environment
Isolated Execution 132

Application RTOS Trusted App Trusted App Trusted Services

Secure OS / Root-of-Trust

Arm Cortex-M4 Arm Cortex-M0+

Figure 2. PSoC 6 Secure MCU offers three levels of isolation

The forecasted explosion of IoT devices will be driven by the availability of cost effective, easy to design, and easy to use
wireless connectivity to the Cloud. The ability for an embedded system to send and receive data is a fundamental enabler for
smartness. Unfortunately, this ability is also an enabler for threats against the very data that makes an IoT device valuable. The
more valuable the data, the more critical that IoT devices implement security capabilities that protect this data. Secure MCUs
such as Cypress’ PSoC 6 MCUs address the needs of secure IoT devices.

Cypress Semiconductor Corporation

198 Champion Court, San Jose CA 95134
phone +1 408.943.2600 fax +1 408.943.6848
toll free +1 800.858.1810 (U.S. only) Press “1” to reach your local sales representative
© 2018 Cypress Semiconductor Corporation. All rights reserved. All other trademarks are the property of their respective owners.

002-23149 **