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
efficiency. 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
definition, already connected and is used widely in a number of applications, from cheap home web-cams to complex industry
systems. By defining 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 first 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 firmware architecture specifications, 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 defined by the PSA through the use of dual Arm Cortex®-M cores,
combined with configurable 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 first step
in the analysis process is to identify data assets handled by the IoT device and their security properties.

!
Identify Data Identify Define Security Requirements
Assets Threats Objectives

Figure 1. Analysis process for designing secure IoT devices

The next steps are to identify threats that target these assets, define 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, firmware defines 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: confidentiality, integrity, and authenticity.

Confidentiality
/känfədenSHēˈalədē/ noun: the state of keeping or being kept secret or private.
Confidentiality 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 confidentiality 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 firmware. Boot firmware ensures that the MCU configures to a known initial state
from which applications can execute. Changes to the boot firmware 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 firmware
example, a digital signature can be used to evaluate authenticity and integrity when upgrading firmware to ensure that only
trusted firmware 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 identifier for the device

Firmware Defines 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 configuration, including network configuration
Each data asset will have security properties associated with it.

Data Asset Secure Properties

Camera ID Integrity
Firmware Confidentiality (optional), Integrity, Authenticity
Firmware Credentials Integrity
Credentials Confidentiality, Integrity
Logs Integrity
Images Confidentiality, Integrity
Configuration Confidentiality (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 confidentiality 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 Confidentiality, Integrity

Man in the Middle Credentials
Images
Configuration Confidentiality, Integrity
Confidentiality Integrity, Confidentiality, Integrity

Firmware Abuse Firmware Confidentiality, Integrity, Authenticity

Tamper Camera ID Integrity
Firmware Confidentiality, Integrity
Firmware Authenticity
Credentials Integrity
Credentials Confidentiality, Integrity
Logs Integrity
Images Confidentiality, Integrity
Configuration Confidentiality, Integrity

Security Objectives
With threats identified, security objectives can now be defined. Security objectives are defined 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 identified previously can be countered by the following security objectives:

Threats

Firmware Abuse
Impersonation

Tamper
MitM
Access Control X X
Secure Storage X
Security Objectives Firmware Authenticity X
Communication X
Secure State X X

Access Control: The IoT device authenticates all actors (human or machine) attempting to access data assets. Prevents
unauthorized access to data assets. Counters spoofing and malware threats where the attacker modifies firmware or installs an
outdated flawed version.
Secure Storage: The IoT device maintains confidentiality (as required) and integrity of data assets. Counters tamper threats.
Firmware Authenticity: The IoT device verifies firmware authenticity prior to boot and prior to upgrade. Counters malware threats.
Communication: The IoT device authenticates remote servers and provides confidentiality (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 verification of firmware 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 Countered Targeted Security

Design Mfg Inventory End Use Term
Objective Threats Data Assets Properties2
Access Spoofing Configuration C N/A N/A N/A Encryption Dead4
Control1 Malware T. Firmware I, A Dig Sign Dig Sign N/A Dig Sign Dead4
Secure Tamper HW ID I N/A eFuse eFuse eFuse eFuse
Storage1 T. Firmware I, A Dig Sign Dig Sign Dig Sign Dig Sign Dead4
User Data C, I N/A N/A N/A Encryption Dead4
Configuration C N/A N/A N/A Encryption Dead4
Keys C, I N/A SEF3 SEF3 SEF3 Dead4
Firmware Auth Malware T. Firmware I, A Dig Sign Dig Sign Dig Sign Dig Sign Dead4

Comm1 MitM User Data C, I N/A N/A N/A Encryption Dead4

Keys C, I N/A SEF3 SEF3 SEF3 Dead4
Secure State Malware T. Firmware I Dig Sign Dig Sign Dig Sign Dig Sign Dead4
Tamper HW ID I, A N/A eFuse eFuse eFuse eFuse
T. Firmware I, A Dig Sign Dig Sign Dig Sign Dig Sign Dead4
User Data C, I N/A N/A Encryption Encryption Dead4
Configuration C N/A N/A Encryption Encryption Dead4
Keys C, I N/A SEF3 SEF3 SEF3 Dead4
Notes:
1. Ideally implemented as a TA in an isolated execution environment
2. C = Confidentiality, 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 firmware is the most-apparent use case of digital signatures. The MCU should provide hardware-based
support of hash and signing to evaluate firmware 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 identification 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 first of such new MCUs. The PSoC 6 MCU architecture was designed for IoT device applications,
offering ultra-low power for extended battery life, efficient 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:
• Configurable 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 firmware hash check failures.
 Rich Execution Isolated Execution
Environment Environment
1 3 2

Application Trusted Trusted Trusted

App App Services

RTOS
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 **