GSMA IoT Security Guidelines (English)

GSM Association Non-confidential
Official Document CLP.11 - IoT Security Guidelines Overview Document
IoT Security Guidelines Overview Document

Version 1.1
07 November 2016
This is a Non-binding Permanent Reference Document of the GSMA
Security Classification: Non-confidential

Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the
Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and
information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted
under the security classification without the prior written approval of the Association.
Copyright Notice
Copyright 2017 GSM Association
Disclaimer
The GSM Association (Association) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept
any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.
The information contained in this document may be subject to change without prior notice.
Antitrust Notice
The information contain herein is in full compliance with the GSM Associations antitrust compliance policy.
V1.1 Page 2 of 43
Table of Contents
1 Introduction 5
1.1 Executive Overview 5
1.2 GSMA IoT Security Guideline Document Set 5
1.2.1 GSMA IoT Security Assessment Checklist 6
1.3 Document Purpose 6
1.4 Intended Audience 7
1.5 Definitions 7
1.6 Abbreviations 8
1.7 References 9
2 The Challenges Created by the Internet of Things 11
2.1 The Availability Challenge 11
2.2 The Identity Challenge 12
2.3 The Privacy Challenge 12
2.4 The Security Challenge 13
3 The Mobile Solution 14
3.1 Addressing the Challenge of Availability 14
3.2 Addressing the Challenge of Identity 14
3.3 Addressing the Challenge of Privacy and Security 15
4 The IoT Model 16
4.1 Service Ecosystem 16
4.2 Endpoint Ecosystem 16
5 Risk Assessments 17
5.1 Goal 18
5.2 Risk Model References 18
6 Privacy Considerations 18
7 Using This Guide Effectively 20
7.1 Evaluating the Technical Model 20
7.2 Review the Current Security Model 21
7.3 Review and Evaluate Recommendations 21
7.4 Implementation and Review 22
7.5 Ongoing Lifecycle 23
8 Example Wearable Heart Rate Monitor 23
8.1 The Endpoint Overview 23
8.2 The Service Overview 24
8.3 The Use Case 24
8.4 The Security Model 25
8.5 The Result 26
8.6 Summary 27
9 Example Personal Drone 27
9.3 The Use Case 28
V1.1 Page 3 of 43

9.5 The Result 30
9.6 Summary 30
10 Example Vehicle Sensor Network 31
10.3 The Use Case 32
10.5 The Result 34
10.6 Summary 34
Annex A Recommended Privacy Considerations for IoT Service providers 35
Annex B Example based upon Automotive Tracking System 39
B.1 Evaluating the Technical Model 39
B.2 Review the Security Model 39
B.3 Review and Assign Security Tasks 40
B.4 Review Recommendations 41
B.5 Review Component Risk 41
B.6 Implementation and Review 41
B.7 Ongoing Lifecycle 42
Annex C Document Management 43
C.1 Document History 43
C.2 Other Information 43
V1.1 Page 4 of 43
1 Introduction
1.1 Executive Overview

The emergence of the Internet of Things (IoT) is creating new service providers who are
looking to develop new, innovative, connected products and services. Analysts have
predicted that hundreds of thousands of new IoT services will connect billions of new IoT
devices over the next decade. This rapid growth of the Internet of Things represents a major
opportunity for all members of the new ecosystem to expand their service offerings and to
increase their customer base.
Analysts have indicated that security issues are a significant inhibitor to the deployment of
many new IoT services and, at the same time, the provision of wide area connectivity to an
ever-widening variety of IoT services will increase the whole ecosystems exposure to fraud
and attack. There is already much evidence to show that attackers are beginning to show
ever greater interest in this area.
As these new service providers develop new and innovative services for particular market
segments, they may be unaware of the threats their service may face. In some cases, the
service provider may not have developed a service that has connected to a communications
network or the internet before and they may not have access to the skills and expertise to
mitigate the risks posed by enabling internet connectivity within their devices. In contrast,
their adversaries understand the technology and security weaknesses, quickly taking
advantage if vulnerabilities are exposed.
Whilst many service providers, such as those in automotive, healthcare, consumer

electronics and municipal services, may see their particular security requirements as being
unique to their market, this is generally not the case. Almost all IoT services are built using
endpoint device and service platform components that contain similar technologies to many
other communications, computing and IT solutions. In addition to this, the threats these
different services face, and the potential solutions to mitigate these threats, are usually very
similar, even if the attackers motivation and the impact of successful security breaches may
vary.
The telecommunications industry, which the GSMA represents, has a long history of
providing secure products and services to their customers. To help ensure that the new IoT
services coming to market are secure, the network operators together with their network,
service and device equipment partners would like to share their security expertise with
service providers who are looking to develop IoT services.
The GSMA has therefore created this set of security guidelines for the benefit of service
providers who are looking to develop new IoT services.
1.2 GSMA IoT Security Guideline Document Set

This document is the first part of a set of GSMA security guideline documents that are
intended to help the nascent Internet of Things industry establish a common understanding
of IoT security issues. The set of guideline documents promotes a methodology for
developing secure IoT Services to ensure security best practices are implemented
V1.1 Page 5 of 43
throughout the life cycle of the service. The documents provide recommendations on how to
mitigate common security threats and weaknesses within IoT Services.
The structure of the GSMA security guideline document set is shown below. It is
recommended that this document, (i.e. the overview document) is read as a primer before
reading the supporting documents.
CLP.11
IoT Security Guidelines Overview
Document CLP.14
IoT Security
CLP.12 CLP.13
+ Guidelines for
Network
IoT Security Guidelines IoT Security Guidelines Operators
for IoT Service for IoT Endpoint
Ecosystem Ecosystem
CLP.17 GSMA IoT Security Self-Assessment Checklist
- GSMA IoT Security Guidelines Document Structure
Network Operators, IoT Service Providers and other partners in the IoT ecosystem are
advised to read GSMA document CLP.14 IoT Security Guidelines for Network Operators
[13] which provides top-level security guidelines for Network Operators who intend to provide
services to IoT Service Providers to ensure system security and data privacy.
1.2.1 GSMA IoT Security Assessment Checklist

An assessment checklist is provided in document CLP.17 [16]. This document enables the
suppliers of IoT products, services and components to self-assess the conformance of their
products, services and components to the GSMA IoT Security Guidelines.
Completing a GSMA IoT Security Assessment Checklist [16] will allow an entity to
demonstrate the security measures they have taken to protect their products, services and
components from cybersecurity risks.
Assessment declarations can be made by submitting a completed declaration to the GSMA.

Please see the following process on the GSMA website:
http://www.gsma.com/iot/iot-security-assessment
1.3 Document Purpose

The goal of the Internet of Things Security Guidelines document set is to provide the
implementer of an IoT technology or service with a set of design guidelines for building a
secure product. To accomplish this task, this document will serve as an overarching model
for interpreting what aspects of a technology or service are relevant to the implementer.
Once these aspects, or components, are identified, the implementer can evaluate the risks
associated with each component, and determine how to compensate for them. Each
component can be broken down into sub-components, where more granular risks will be
described. Each risk shall be assigned a priority, to assist the implementer in determining the
V1.1 Page 6 of 43
cost of the attack, as well as the cost of remediation, and the cost, if any, of not addressing
the risk.
The scope of this document is limited to recommendations pertaining to the design and
implementation of IoT services.
This document is not intended to drive the creation of new IoT specifications or standards,
but will refer to currently available solutions, standards and best practice.
This document is not intended to accelerate the obsolescence of existing IoT Services.
It is noted that adherence to national laws and regulations for a particular territory may,
where necessary, overrule the guidelines stated in this document.
1.4 Intended Audience

The primary audience for this document are:
IoT Service Providers - enterprises or organisations who are looking to develop new
and innovative connected products and services. Some of the many fields IoT
Service Providers operate in include smart homes, smart cities, automotive, transport,
heath, utilities and consumer electronics.
IoT Device Manufacturers - providers of IoT Devices to IoT Service Providers to
enable IoT Services.
IoT Developers - build IoT Services on behalf of IoT Service Providers.
Network Operators who are themselves IoT Service Providers or build IoT Services
on behalf of IoT Service Providers.
1.5 Definitions
Term Description
Identifier of a network connection point to which an endpoint device
Access Point
attaches. They are associated with different service types, and in many cases
Name
are configured per network operator.
A hacker, threat agent, threat actor, fraudster or other malicious threat to an IoT
Service typically with the intent of retrieving, destroying, restricting or falsifying
information. This threat could come from an individual criminal, organised
Attacker
crime, terrorism, hostile governments and their agencies, industrial espionage,
hacking groups, political activists, hobbyist hackers, researchers, as well as
unintentional security and privacy breaches.
A network of remote servers on the internet that host, store, manage, and
Cloud
process applications and their data.
This Endpoint model has a persistent connection to a back-end server over a
Complex Endpoint long-distance communications link such as cellular, satellite, or a hardwired
connection such as Ethernet. See CLP.13 [4] for further information.
Components Refers to the components contained in documents CLP.12 [3] and CLP.13 [4]
Embedded SIM A SIM which is not intended to be removed or replaced in the device, and
enables the secure changing of profiles as per GSMA SGP.01 [2].
Endpoint A generic term for a lightweight endpoint, Complex Endpoint, gateway or other
connected device. See CLP.13 [4] for further information.
V1.1 Page 7 of 43
Term Description
Endpoint Any configuration of low complexity devices, rich devices, and gateways that
Ecosystem connect the physical world to the digital world in novel ways. See section 4.2 for
further information.
The Internet of Things (IoT) describes the coordination of multiple machines,
devices and appliances connected to the Internet through multiple networks.
These devices include everyday objects such as tablets and consumer
Internet of Things
electronics, and other machines such as vehicles, monitors and sensors
equipped with communication capabilities that allow them to send and receive
data.
Any computer program that leverages data from IoT devices to perform the
IoT Service
service.
IoT Service Enterprises or organisations who are looking to develop new and innovative
Provider connected products and services.
The operator and owner of the communication network that connects the IoT
Network Operator
Endpoint Device to the IoT Service Ecosystem.
Organizational A set of cryptographic policies and procedures that govern how identities,
Root of Trust applications, and communications can and should be cryptographically secured.
Refers to the recommendations contained in documents CLP.12 [3] and CLP.13
Recommendations
[4]
Risk Refers to the risks contained in documents CLP.12 [3] and CLP.13 [4]
Security Tasks Refers to the security tasks contained in documents CLP.12 [3] and CLP.13 [4]
Service Access A point of entry into an IoT Services back end infrastructure via a
Point communications network.
The set of services, platforms, protocols, and other technologies required to
IoT Service
provide capabilities and collect data from Endpoints deployed in the field. See
Ecosystem
section 3.1 for further information.
Subscriber Identity The smart card used by a mobile network to authenticate devices for
Module (SIM) connection to the mobile network and access to network services.
A Secure Element Platform specified in ETSI TS 102 221 that can support
multiple standardized network or service authentication applications in
UICC
cryptographically separated security domains. It may be embodied in
embedded form factors specified in ETSI TS 102 671.
1.6 Abbreviations
Term Description
3GPP 3rd Generation Project Partnership
API Application Program Interface
APN Access Point Name
CERT Computer Emergency Response Team
CLP GSMAs Internet of Things Programme
CPU Central Processing Unit
EAP Extensible Authentication Protocol
EEPROM Electrically Erasable Programmable Read-Only Memory
V1.1 Page 8 of 43
Term Description
GBA Generic Bootstrapping Architecture
GPS Global Positioning System
GSMA GSM Association
GUI Graphic User Interface
HIPAA Health Insurance Portability and Accountability Act
IoT Internet of Things
LPWA Low Power Wide Area
NIST National Institute of Standards and Technology
OBD On Board Diagnostics
OCTAVE Operationally Critical Threat, Asset, and Vulnerability Evaluation
OMA Open Mobile Alliance
PIA Privacy Impact Assessment
PII Personally Identifiable Information
RAM Random Access Memory
SIM Subscriber Identity Module
1.7 References
Ref Doc Number Title
The Mobile Economy 2015
[1] n/a
http://www.gsmamobileeconomy.com/
Embedded SIM Remote Provisioning Architecture
[2] SGP.01
http://www.gsma.com/iot/embedded-sim/
IoT Security Guidelines for IoT Service Ecosystem
[3] CLP.12
www.gsma.com/iot//iot-security-guidelines-for-iot-service-ecosystem/
IoT Security Guidelines for IoT Endpoint Ecosystem
[4] CLP.13
www.gsma.com/iot/iot-security-guidelines-for-endpoint-ecosystem/
NIST Risk Management Framework
[5] n/a
http://csrc.nist.gov/groups/SMA/fisma/framework.html
Introducing OCTAVE Allegro: Improving the Information Security
CMU/SEI-
[6] Risk Assessment Process
2007-TR-012
http://www.cert.org/resilience/products-services/octave/
[7] Not Used Not Used
Generic Authentication Architecture (GAA); Generic Bootstrapping
[8] TS 33.220 Architecture (GBA)
www.3gpp.org
Extensible Authentication Protocol Method for Global System for Mobile
[9] RFC 4186 Communications (GSM) Subscriber Identity Modules (EAP-SIM)
www.ietf.org
Conducting privacy impact assessments code of practice
[10] n/a
https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-
V1.1 Page 9 of 43

practice.pdf
Open Mobile Alliance
[11] n/a
http://openmobilealliance.org/
oneM2M
[12] n/a
http://www.onem2m.org/
IoT Security Guidelines for Network Operators
[13] CLP.14
www.gsma.com/iot/iot-security-guidelines-for-network-operators/
Report of the Special Rapporteur on the promotion and protection of the
right to freedom of opinion and expression, Frank La Rue*
[14] GE.11-13201
www.ohchr.org/english/bodies/hrcouncil/docs/17session/A.HRC.17.27_en.p
df
Right to Internet Access
[15] n/a
https://en.wikipedia.org/wiki/Right_to_Internet_access
GSMA IoT Security Assessment Checklist
[16] CLP.17
V1.1 Page 10 of 43
2 The Challenges Created by the Internet of Things

Several years ago a United Nations special report recommended that the Internet is a basic
human right, and that all people of the world should have access to broadband services [14].
More recently laws are being adopted in counties such as France, Greece, Spain and others
[15], to ensure that Internet access is broadly available and/or to prevent the state from
unreasonably restricting an individual's access to information and the Internet.
These declarations are the result of the rapid social and technological changes that have
stemmed from the growth of the Internet. This has resulted in the Internet becoming a way of
life, one of the primary sources of all classes of information, and the most common method
for maintaining connectivity to loved ones and peers. The Internet is not simply a technology,
it has become a part of us.
In concert with the growing desire to maintain connectivity, a technological explosion has
occurred over the past few years. While technologists have declared The Internet of Things
is coming! for over a decade, the interest in ubiquitous access to information and the cost
model required to do so had not yet combined into a practical business model until the past
five years. At this point, component costs sharply decreased, while access to wireless
services and the speed of those services have dramatically increased. Protocols, battery life,
and even business models have all evolved to accommodate our ever increasing demand
for information and connectivity.
And that, in essence, is what the Internet of Things is all about. It isnt really about things. Its
about Us. The Internet of Us. The human and digital experiences no longer sit side-by-side,
they are bound ever tighter by this new way of life.
And because the human physical experience is bound more to the digital world than ever
before, it must be protected, as digital security now directly impacts the physical world more
than ever. The Internet of Things is an excellent opportunity for the world to move forward
together, in order to create ever greater databases of knowledge, shared experiences, and
explosions of innovation. But, for this to work effectively, the technologies that drive this
connectivity must be secured, to enforce the privacy, reliability, and quality of services
necessary to ensure that this great utility, this imperative basic need, is kept available to all
those that require it.
For the Internet of Things to evolve effectively, we must resolve the security challenges
inherent to its growth. These challenges are:
Availability: Ensuring constant connectivity between Endpoints and their respective

services
Identity: Authenticating Endpoints, services, and the customer or end-user operating
the Endpoint
Privacy: Reducing the potential for harm to individual end-users
Security: Ensuring that system integrity can be verified, tracked, and monitored
2.1 The Availability Challenge

For the Internet of Things to evolve at its expected pace, Endpoint devices must be able to
constantly communicate with each other, end-users, and back-end services. To accomplish
this, new technologies need to be designed that allow persistent connectivity. This dovetails
V1.1 Page 11 of 43
well with the challenge of ubiquitous Internet access for the modern world. For this to
succeed, several questions must be answered:
How can Low Power Wide Area Networks (LPWAN) be implemented with a similar
level of security to modern cellular systems?
How can multiple mobile operators support the same level of security as new IoT
Endpoints migrate across network boundaries?
How can network trust be forwarded to capillary Endpoints that rely on Gateway
Endpoints for communication?
How can the power constraints of Lightweight Endpoints be addressed in secure
communications environments?
2.2 The Identity Challenge

In order for an Endpoint to function within an IoT product or service ecosystem, it must be
capable of securely identifying itself to its peers and services. This critical and fundamental
aspect of IoT technology ensures that services and peers are able to guarantee to what
and to whom data is being delivered. Access to information and services isnt the only
issue directly tied to identity. We also must ask the questions:
Can the user operating the Endpoint be strongly associated with the Endpoints
identity?
How can services and peers verify the identity of the end-user by verifying the identity
of the Endpoint?
Will Endpoint security technology be capable of securely authenticating peers and
services?
Can rogue services and peers impersonate authorized services and peers?
How is the identity of a device secured from tampering or manipulation?
2.3 The Privacy Challenge

Privacy can no longer be seen as an add-on to existing products and services. Because the
physical world is directly affected by actions taken in the digital world, privacy must be
designed into products from the ground up, to ensure that every action is authorized and
every identity is verified while guaranteeing that these actions and the associated meta-data
are not exposed to unauthorized parties. This can only be achieved by defining the proper
architecture for a product or service, and is exceptionally difficult and expensive to perform
retroactively.
Medical devices, automotive solutions, industrial control systems, home automation, building
and security systems, and more, all directly impact human physical lives. It is the duty of the
engineers to uphold these products and services to the highest level of assurance possible,
to reduce the potential for physical harm as well as the exposure of privacy relevant data.
Therefore, we must ask ourselves how privacy affects not only the end-user, but how IoT
technologies are designed:
Is the identity of an Endpoint exposed to unauthorized users?

Can unique Endpoint or IoT Service identifiers allow an end-user or Endpoint to be
physically monitored or tracked?
V1.1 Page 12 of 43
Is data emanating from an Endpoint or IoT Service indicative of or directly associated

with physical end-user attributes such as location, action, or a state, such as sleeping
or awake?
Is confidentiality and integrity employed with sufficient security to ensure that patterns
in the resultant cipher-text cannot be observed?
How does the product or service store or handle user-specific Personally Identifiable
Information (PII)?
Can the end-user control the storage or use of PII in the IoT Service or product?
2.4 The Security Challenge

While Internet security has drastically improved over the past several decades, there have
been several significant gaps in the overall health of modern technology. These gaps have
been most evident in embedded systems and in cloud services - the two primary
components in IoT technology.
In order for IoT to evolve while not exposing massive groups of users and physical systems
to risk, information security practices must be enforced on both Endpoints and IoT Services.
Are security best practices incorporated into the product or service at the start of the
project?
Is the security life-cycle incorporated into the Software or Product Development Life
Cycle?
Is application security being applied to both services and applications running on the
embedded system?
Is a Trusted Computing Base (TCB) implemented in both the Endpoint and the
Service Ecosystem?
How does the TCB enforce self-verification of application images and services?
Can the Endpoint or IoT Service detect if there is an anomaly in its configuration or
application?
How are Endpoints monitored for anomalies indicative of malicious behaviour?
How is authentication and identity tied to the product or service security process?
What incident response plan is defined for detected anomalies indicative of a
compromise?
How are services and resources segmented to ensure a compromise can be
contained quickly and effectively?
How are services and resources restored after a compromise?
V1.1 Page 13 of 43
3 The Mobile Solution

While there have been a myriad of technologies that offer connectivity solutions for IoT, none
shape the future of IoT better than mobile networks. Mobile networks offered the first
wireless services to consumers and industry over twenty years ago, and have been building
reliable, available, secure, and cost effective services ever since. The mobile industry has
extensive experience in network availability due to the volatile nature of wireless radio
networks managed over long distances. Network identity has been a challenge that has
spawned numerous standards, device technologies, protocols and analytics models. Privacy
and security are constant concerns of the mobile industry, who have worked to decrease the
potential for abuses, identity theft, and fraud in all mobile technology.
3.1 Addressing the Challenge of Availability

According the GSMAs The Mobile Economy 2015 report [1]:
The mobile industry continues to scale rapidly, with a total of 3.6 billion unique mobile
subscribers at the end of 2014. Half of the worlds population now has a mobile
subscriptionup from just one in five 10 years ago and an additional one billion
subscribers are predicted by 2020, taking the global penetration rate to approximately
60%. There were 7.1 billion global SIM connections at the end of 2014, and a further
243 million machine-to-machine connections.
There is an accelerating technology shift to mobile broadband networks across the
world. Mobile broadband connections (i.e. 3G and 4G technologies) accounted for
just under 40% of total connections at the end of 2014, but by 2020 will increase to
almost 70% of the total.
While 2G remains the dominant network technology globally today, its position has
already declined materially. 2G connections accounted for 90% of the total in 2008,
but this had fallen to around 60% at the end of 2014. In absolute terms, the number of
2G connections peaked in 2013 and fell by 6% during 2014.
The ongoing technology migration to higher speed networks is also facilitated by
significant operator investments. Recent research from GSMA predicts that more
than four out of five people will have access to 3G networks by 2020, up from 70%
today. The report also highlights that 4G networks are being rolled out at a faster
pace than was the case with 3G. While it took 10 years for 3G network coverage to
reach half of the global population, it will take 4G networks just eight years after
launch to reach the same milestone in 2017.
In the future we will also see the integration of Low-Power Wire-Area (LPWA) wireless
technology into the cellular communications space covering the needs of IoT. This class of
communications technology offers the wide area, wireless connectivity of todays mobile
networks at a fraction of the power required to communicate effectively. Mobile operators will
be integrating LPWA protocols and technologies into their offerings to provide services and
solutions to businesses in the near future.
3.2 Addressing the Challenge of Identity

Identity management has been a challenge for decades and has strengthened the mobile
industrys standards and technology offerings significantly. While the mobile industry is
typically associated with the removable SIM card, the GSMA has created a SIM based
V1.1 Page 14 of 43
solution called the Embedded SIM Remote Provisioning Architecture [2] which is
appropriate for use in IoT to enable deeper component level integration into Endpoint
devices, reduced production costs and the management of connectivity via Over-The-Air
(OTA) platforms to enable the connectivity of the IoT Endpoint devices for their whole
lifetime.
Identity technologies, such as the Embedded SIM, are designed as trust anchors that
integrate security by default. They are manufactured to withstand attacks such as:
Glitching
Side-channel analysis
Passive data interception
Physical tampering
Identity theft
An excellent advancement to this already security hardened technology is that new

generations of these trust anchors incorporate an important addition to the IoT landscape.
These technologies will be dual use. They wont simply be used to verify the security of the
network, they will also be capable of securing application communications and the
application itself, similar to traditional computing trust anchors.
This dual use capability will be further augmented by the integration of mobile industry
security specifications such as those provided by 3GPP GBA [8], OMA [11], oneM2M [12]
and others. These technologies will help to securely provision devices in the field, securely
enable over-the-air firmware updates, and manage device capabilities and identity.
These technologies, when used together, will ease the currently complex engineering
processes and combine it into one simple component. Instead of application engineers
building complex technologies that they themselves have to manage, the network operator,
who already manages the network identity, can perform this on behalf of the application.
This not only reduces the engineering complexity, but the businesss daily management
requirements.
3.3 Addressing the Challenge of Privacy and Security

Along with the capabilities of the SIM, the mobile industry has developed resilient protocols,
processes, and monitoring systems to enable security and reduce the potential for fraud and
other malicious activities. For example, 3G and 4G technologies use mutual authentication
to verify the identity of the Endpoint and the network. This process helps ensure that
adversaries are unable to intercept communications.
Furthermore, network technology can be secured through the use of the SIM and
technologies such as GBA [8] or EAP-SIM [9]. By using these technologies, the SIM can be
provisioned with a session security key that can be used in communications with application
network peers over well-known protocols. This process can diminish the potential for
adversaries to manipulate the application protocol to compromise the devices or service.
Thus, it is possible to secure both the network and the application with this model.
V1.1 Page 15 of 43
4 The IoT Model

The figure below shows the standard IoT model used throughout these documents is
depicted as components of the service and endpoint ecosystems. Each component is
composed of sub-components, which are detailed in a document that focuses solely on the
primary component. For example, the Endpoint component, and its respective risks, are
outlined in the Endpoint Ecosystem document [3] provided within this document set and the
Service components are outlined in the Service Ecosystem document [4].
Example IoT Model
In almost all modern IoT service or product models, this diagram defines the primary
components that are required when deploying a production-ready technology.
Communications network components are inherent to IoT and, for the purposes of this
model, provide the connection between the two ecosystems with each end of the
communication link discussed within the appropriate Endpoint Ecosystem and Service
Ecosystem document.
Specific network security guideline recommendations for Network Operators can be found in
the GSMAs IoT Security Guidelines for Network Operators [13].
4.1 Service Ecosystem

The Service Ecosystem represents the set of services, platforms, protocols, and other
technologies required to provide capabilities and collect data from Endpoints deployed in the
field. This ecosystem typically gathers data from Endpoints and stores them within its server
environment. This data can be rendered to the user by handing elegant visual depictions of
the data to various user interfaces. This data, often in the form of metrics, parameters or
commands, can also be handed off to authorized third parties via an API originating at the
service infrastructure, which is commonly how IoT Service Providers monetize the service.
The Service Ecosystem security guidelines to be used in conjunction with the process
described in this overview document can be found in CLP.12 IoT Security Guidelines for IoT
Service Ecosystem [4]
4.2 Endpoint Ecosystem

The Endpoint Ecosystem [4] consists of low complexity devices, rich devices and gateways
that connect the physical world to the digital world in via several types of wired and wireless
networks. Examples of common Endpoints are motion sensors, digital door-locks,
V1.1 Page 16 of 43
automotive telematics systems, sensor-driven industrial control systems, and more.

Endpoints gather metrics from the physical environment around them, and push that data in
different formats via a capillary or cellular network to the Service Ecosystem, often receiving
instructions or actions in response. They may also include rich user interfaces that render
data obtained either through the Endpoint itself, or from the Service Ecosystem.
The Endpoint Ecosystem security guidelines to be used in conjunction with the process
described in this overview document can be found in CLP.13 IoT Security Guidelines for IoT
Endpoint Ecosystem [13]
5 Risk Assessments
While the concept of a risk assessment has been around for many decades, many
businesses are more familiar with applying the concept to general business risk than to
information security. However, an information security risk assessment process is also
imperative toward the secure operation and longevity of the technological side of a business.
Obviously, in Internet of Things technology, where the engineering team is a critical
component to the success of the business, the risk assessment process should be the first
step the organization takes to building a security practice.
While every organization should create a granular perspective of technological risk, there are
high level questions that function as starting points for the risk assessment process
What assets (digital or physical) need to be protected?

What groups of people (tangible or intangible) are potential threat actors?
What is a threat to the organization?
What is a vulnerability?
What would the result be if a protected asset were compromised?
What is the probability of the asset being compromised?
What would the result be when put in context with different groups of attackers?
What is the value of the asset to the organization and its partners?
What is the safety impact of the asset being compromised?
What can be done to remediate or mitigate the potential for vulnerability?
How can new or evolving gaps in security be monitored?
What risks cannot be resolved and what do they mean to the organization?
What budget should be applied toward incident response, monitoring, and risk
remediation?
These starting points will help the engineering and information technology teams work more
effectively with the organization. The goal is to ensure that the technical side of the business
agrees on the risks, values, and remediation plans with the executive side of the business.
Forcing the teams to work together will help create a more realistic perspective of not only
the risk to the business, but the value of assets. This will directly affect the budget that
should be applied toward resolving outstanding gaps in security.
There are some risks that simply cannot be resolved. Some of these risks will be discussed
in these guidelines. The organization should evaluate these risks and determine whether
they are acceptable. This will provide the business with a realistic understanding of their
limitations, the technologys limitations, and their ability to react to certain types of threats.
V1.1 Page 17 of 43
There is nothing more monetarily draining than presuming that all security gaps can be
resolved in a cost-effective manner.
5.1 Goal
The goal of a risk assessment is to create (or update) a set of policies, procedures, and
controls that remediate, monitor, and respond to gaps in security found in the technical part
of the organization. The output of the risk assessment should help the business adjust not
only its technology, but the way the technology is managed, designed, and deployed. Once
the risk assessment output more adequately describes the value of the information and
resources used by the organization, the overall business can be secured through the
enhancement of its personnel, processes, and policies.
Remember, the core benefits to using the output of a risk assessment are:
Informing personnel
Enhancing processes
Defining (or updating) policies
Executing remediation
Monitoring for new gaps
Enhancing the product or service
This, essentially helps the organization enforce a base platform for personnel and process
security. This platform then should be incorporated into a cycle that constantly assesses and
refines the overall roles and responsibilities of the organization.
5.2 Risk Model References

Rather than attempt to define a risk assessment and threat modelling process here, please
review the following references for an adequate depiction and walk-through of the risk
assessment process:
National Institute of Standards and Technology (NIST)s Risk Management

Framework [5]
Computer Emergency Response Team (CERT)s OCTAVE model [6]
6 Privacy Considerations
Many IoT services and products will be designed to create, collect, or share data. Some of
this data may not be considered personal data or impact a consumers privacy, and
therefore, not subject to data protection and privacy laws. This data could include
information about the physical state of the machines, internal diagnostic data, or metrics
regarding the state of the network.
However, many IoT services will involve data about or related to individual consumers and
will be subject to general data protection and privacy laws. Where mobile operators provide
IoT services they will also be subject to telecommunications-specific privacy and security
rules. Consumer focused IoT services are likely to involve the generation, distribution and
use of detailed data that could impact an individuals privacy. For example, drawing
inferences about their health or developing profiles based on their shopping habits and
V1.1 Page 18 of 43
locations. As consumer IoT services gain in popularity, more consumer data will be created,
analysed in real-time and shared between multiple parties across national borders.
Where data relates to specific individuals, this complex, connected ecosystem may raise
concerns from the consumer over:
Who is collecting, sharing and using individuals data?

What specific data is being acquired?
Where is the data being acquired from (what technologies or interfaces)?
When is the data being collected?
Why is the data being collected from the user?
How the privacy (not just the security) of individuals information is ensured?
Are individuals in control over how their data is shared and how companies will use
it?
All providers of IoT services that rely on consumer data as well as any partner companies
capturing or using such data have an obligation to respect individuals privacy and keep
personally identifiable or privacy-invasive information secure.
A key challenge for IoT service providers is that there are multiple, and often-inconsistent,
laws dealing with privacy and data protection. Different laws may apply in different
countries, depending on the types of data involved, as well as the industry sector and
services that the service provider is offering. This has implications for a number of
consumer-oriented IoT service providers;
A connected vehicle, for example, can move between different countries, meaning the
associated data transfers may be governed by several different legal jurisdictions. In-car
sensors tracking the location of the car (static or dynamic) and its frequent destinations could
be used to infer a number of insights about the drivers lifestyle, hobbies or religion, which
the driver may consider personal information. Additionally, insights about driving habits
through on-board diagnostics sensors might be shared with insurance companies who
might use those insights to impose a higher premium and therefore discriminate against the
driver without their knowledge.
IoT services and devices (including connected cars) can also move between different
sovereign territories and therefore different legal jurisdictions. In many cases, an individuals
personal data may transit or reside in jurisdictions different from the individual. These are
important issues that need to be considered before a multi-national IoT Service is deployed.
Another challenge is that most data protection laws require companies collecting consumers
data to get the affected consumers (also known as the data subject) consent before
processing certain categories of personal data such as health related data. Most laws
define personal data as any information that relates to an identified or identifiable living,
natural person.
But as more and more devices are connected to the Internet, more and more data about
individuals will be collected and analysed and possibly impact their privacy, without
necessarily being considered personal by law. The combination of massive data volumes,
Cloud storage and predictive analytics can provide detailed profiles of users. In particular, it
V1.1 Page 19 of 43
may become challenging to truly anonymise information and personal information can be
inferred from other data types.
The need to maintain the privacy of sensitive, health data records is well recognised, not
least due to the potential for commercial abuse of such records. In the United States of
America, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) includes
privacy and security requirements to mitigate the risks of unauthorised disclosure of health
records.
HIPAA, like many other regulations such as those in the European Union, only applies if the
health data is personally identifiable. The data stored in a blood monitoring device (which
does not identify the user) would not be covered by these requirements, whereas that same
data in a smartphone app or in a Cloud server is likely to be covered because it is able to be
linked to an individual (in the case of a smartphone because the phone will almost certainly
contain other data identifying the user and in a Cloud server because it will be associated
with an identifiable user account). Policymakers around the world are realising that
information and insights about people can impact their privacy even if they are not defined
as personally identifiable. They are therefore beginning to adopt more risk-based
approaches to regulation but also considering the wider privacy implications of data use
rather than focusing on legal definitions.
In order to build trust in the IoT ecosystem Governments should ensure data protection and
privacy legislation is technology-neutral and that rules are applied consistently to all players
in the internet ecosystem. Furthermore, in order for IoT Service Providers to minimise the
need for formal regulatory intervention, we recommend that they follow the steps described
in Annex A at the early development stages of their IoT service or product.
7 Using This Guide Effectively

While security is best implemented at the start of an engineering project, this guide can also
assist in organizations that have already designed, fabricated, and even deployed an IoT
product or service. Regardless of which stage the readers product or service has reached,
there is a useful process that should be followed to get the most benefit from this set of
documents:
Evaluate the technical model

Review the current product or services Security Model
Review and evaluate Recommendations
Implementation and Review
Ongoing Lifecycle
7.1 Evaluating the Technical Model

The first and most important step in the process is understanding the organizations own IoT
product or service. In order to perform a security review and risk assessment, the team
should be familiarized with each component used in the organizations solution, how
components interact, and how the components interact with their environment. Without a
clear understanding of how the product or service was (or will be) built, a review will be
incomplete.
V1.1 Page 20 of 43
Start by making a document describing each component used in the system. Identify how
the component is sourced, how it is used, what privilege level it requires, and how it is
integrated into the overall solution. Map each component to the technologies described in
the Model section of each Endpoint Ecosystem [3] and Service Ecosystem [4] guidelines
documents. It is acceptable if the document doesnt specifically match a component, as it
should map the components general class. Simply use the class of component, such as a
microcontroller, communications module, or trust anchor, as the context. Consider the
following questions:
What components are used to build the product or service?

What inputs and outputs are applicable to the given component?
What security controls are already applied to these inputs and outputs?
What privilege level is applied to the component?
Who in the organization is responsible for implementing the component?
Who in the organization is responsible for monitoring and managing the component?
What process is in place to remediate risks observed in the component?
These questions, when answered, will provide an understanding of how the technical
components interact with each other, and how the overall product or service is affected by
each component.
This process corresponds with the first and second phases of the CERT OCTAVE risk
assessment model [6], or the Frame stage of the NIST Risk Management Framework [5].
This assists in the development of a profile for each critical business asset, the development
of security objectives, and establishes a foundation for how the company will assess,
monitor, and respond to risk.
7.2 Review the Current Security Model

Next, read through the security model section of the Endpoint or Service being assessed.
This section will help the reader understand the model that an Attacker will use to
compromise a given technology. This model is based on years of experience performing
security assessments on, reverse engineering, and designing embedded systems.
Once the security model has been reviewed, the reader should have a better understanding
of what technologies are most vulnerable, or most desirable to the Attacker, in the product or
service being developed. This information should be shared with the organization, to ensure
that both engineers and leadership understand the risks and threats to the current model.
However, it should be noted that the organization should not take steps to adjust their
security model at this time. It is too early to make concise architectural changes.
This process again corresponds to the first and second phases of the CERT OCTAVE model
[6], or the Frame stage of the NIST Risk Management Framework [5]. Reviewing the security
model helps enhance the technical model by identifying potential gaps in security and
shining a spotlight on security objectives that should be prioritized.
7.3 Review and Evaluate Recommendations

The Recommendations section should be reviewed at this time to evaluate how Security
Tasks can be resolved. This section will not only provide methodologies for implementing
V1.1 Page 21 of 43
recommendations, but will provide insight into the challenges involved in implementing the
particular recommendation.
For each recommendation, a Method section is provided. This section will outline
methodologies that assist in the remediation or mitigation of the corresponding security risk.
These methods, while presented from a high level, will outline concepts that reduce risk from
a holistic perspective, to ensure the greatest amount of gain is acquired from a reasonable
and practical amount of effort.
An Expense section is provided to discuss, where applicable, extra financial expenses that
the organization should prepare for when implementing a particular recommendation. While
most expenses, such as engineering time and raw materials, are fairly obvious, less obvious
expenses can alter the finances applied to products and services whose profit margins and
budgetary limits have already been defined by the business leadership. While specific
numbers are not provided, technologies and services are specified that may incur additional
costs.
A Risk section is also provided so the reader understands the gaps in security that are likely
to result from not implementing a particular recommendation. While the business may accept
that some risks are within the businesss operating guidelines, the reader should review
each risk section to ensure that the business fully understands the side effects of not
implementing (or not correctly implementing) a given recommendation. This may seem
straight forward for recommendations such as Encrypt Data, but the subtlety of some
threats, such as replay attacks against messages that are not cryptographically unique, may
be a surprise to the reader at a later date.
In some cases, references are provided for further review. While this document does not
provide detailed information on every technology, risk, or remediation plan, other standards
and time-proven strategies do. This set of documents will provide references to those
materials, where applicable, within each recommendation.
The output from reviewing the Recommendations section should directly tie into the Security
Tasks section. The Security Tasks should now be filled out with Recommendations that are
appropriate for implementing the Security Tasks correctly. These Security Tasks will then tie
back to specific Components assigned to members of the organization.
Evaluating recommendations corresponds to the Assess step of the NIST Risk Management
Framework [5], and steps six, seven, and eight of the CERT OCTAVE methodology [6].
7.4 Implementation and Review

By this stage, clear Security Tasks have been outlined and the business will have a better
comprehension of their security vulnerabilities, their value and their risk. The business shall
now create a clear architectural model for each Component being adjusted, and use the Risk
Assessment process chosen by the organization to develop a threat model of each
Component, incorporating the Recommendations and Risks that are appropriate for each
Component and Security Task. When the architectural model is completed, the organization
can begin implementing each Recommendation in order to fulfil the Security Tasks.
When the implementation is complete, the organization should review the Risks in both the
Recommendations subsection and the Component sections. The organization should ensure
V1.1 Page 22 of 43
that the implementation fulfils the requirements set forth by these sections. The organization
should then ensure that the implementation solves security with regard to the context in
which the Component is designed in the organizations product or service, as these
documents cannot fully address every product or service being designed in the field. If
possible, have a third party consulting firm evaluate the implementation to ensure that it
does indeed adhere to security best practices.
Implementation and review corresponds with the Respond component of the NIST Risk
Management Framework [5], and step eight of the CERT OCTAVE model [6].
7.5 Ongoing Lifecycle

The security life cycle does not stop at this juncture. Rather, security is an inherent part of
the overall engineering of a process. Endpoints and IoT Services have a lifetime, and must
be continually serviced throughout that lifetime, just like a living organism.
Requirements change over time. Cryptographic algorithms become dated or deprecated.

New protocols and radio technologies must interoperate with the product or service. This
ever changing ecosystem our embedded products are deployed in must be constantly
reviewed to ensure that confidentiality, integrity, availability, and authenticity are maintained.
Managing the ongoing security lifecycle corresponds with the Monitor and Frame
components of the NIST Risk Management Framework [5], and steps one, four, and five of
the CERT OCTAVE model [6].
8 Example Wearable Heart Rate Monitor

In this example, a simple Heart Rate Monitor (HRM) design will be evaluated using this set
of guidelines. The endpoint will be assessed using the Endpoint Ecosystem document, while
the service side of the design will be assessed using the Service Ecosystem document.
8.1 The Endpoint Overview

First, lets start by evaluating the hardware design of the endpoint.
Simple HRM and Primary Components
The HRM is composed of standard components for a simple wireless wearable device: an
ambient light photo sensor and a Bluetooth Low Energy (BLE) transceiver enabled
microcontroller. The sensor is used to capture pulse rate data, while the microcontroller
V1.1 Page 23 of 43
analyses the data emitting from the sensor and chooses what data to send over the built-in
BLE transceiver. In this example, the BLE stack used is version 4.2.
A coin cell battery is used in this example to transmit data from the HRM to another device,
such as a smart-phone or tablet. No other components are required for this device to
function.
According to the Endpoint Ecosystem document, this device would fit into the Lightweight
Endpoint class of devices.
8.2 The Service Overview

From a service perspective, the application on the smart-phone or tablet pushes metrics
from the endpoint up to a back-end service over any available network connection. The
back-end service for the application simply associates the device owner with the metrics
being captured and stores them in a database local to the application server.
Visualization of the data can be achieved using the mobile application, or via the services
website. Users of the wearable technology can log into the service providers website to
perform more actions with the metrics captured by the endpoint.
This is a very simple and common service model with no custom or unnecessary
complexities.
Flow of Data to Simple Back End Service
8.3 The Use Case

The business developing this technology intends the end user to track their pulse data
throughout the day, storing it in both the application and the back-end database. The
intention is to allow users to review their heart rate over time to track their overall health.
Users can watch their health improve or worsen over time, depending on whether they are
maintaining a healthy life style. This allows the users to incentivize themselves by evaluating
both positive and negative trends in their HRM data.
V1.1 Page 24 of 43
The business intends to use this data to partner with medical device manufacturers, health
care providers, and other organizations that can use these metrics to identify whether a
consumer is more or less likely to incur a health-related event, such as a heart attack or a
stroke.
8.4 The Security Model

The engineering team at this example business leveraged the Frequently Asked Security
Question sections of the Endpoint and Service documents to determine what issues are
most relevant to their product and service.
From an endpoint perspective, the team learned the following issues are of concern:
Cloning
Endpoint impersonation
Service impersonation
Ensuring privacy
From a service perspective, the team decided the following issues are of concern:
Cloning
Hacked services
Identifying anomalous endpoint behaviour
Limiting compromise
Reducing data loss
Reducing exploitation
Managing user privacy
Improving availability
The team reviewed the recommendations for each of the above issues, as suggested by
each relevant Frequently Asked Security Question section. The team then chose to
implement recommendations that were cost-effective improvements that ensured the
greatest amount of security.
In this example model, the endpoint would not require a substantial change. Since the
endpoint has very little functionality, minimal security can be employed on the endpoint for
both application security and communication. Since the endpoint application is flashed on a
single device, as long as the device firmware is locked, there is no real threat of attack
against the endpoint within the given use case.
However, since privacy is an issue, the organization should employ at least a Personalized
PSK version of a Trusted Computing Base (TCB). This would ensure that encryption tokens
were unique to each endpoint, so that one compromised endpoint cannot compromise all
endpoints. If the personalized (unique) keys were encoded into the locked microcontroller, it
would be reasonable to believe that this use case were adequately secured from the threat
of cloning, impersonation, and privacy issues. Review the IoT Service [3] and Endpoint [4]
documents for a more complete discussion on what a Trusted Computing Base is within
each ecosystems context.
V1.1 Page 25 of 43
The server infrastructure, however, requires a significant amount of changes. The engineers
realize that, according to the recommendations, they are at serious risk of abuse. The
following issues are acknowledged:
There is no security front-end diminishing the effects of a Denial of Service attack

There are no ingress or egress controls limiting the flow of traffic to or from services
There is no separation of duties between service tiers
There is no separate secured database containing Personalized PSK tokens
No adequate security measures are implemented in the service operating system
There are no metrics taken to evaluate anomalous endpoint behaviour
8.5 The Result

After implementing the recommendations, the organization has a much better defined back-
end service architecture that adequately addresses the risks identified through the
guidelines.
Resultant Service Ecosystem
In the above figure, the changes to the service ecosystem are easily observable. Each class
of service has been broken into separate tiers to help secure and scale the technology easily
in the event that demand spikes. Two additional tiers were added, a database tier and an
authentication tier, to separate critical systems from services that directly interface with the
outside world. A security front-end was implemented to help guard the internal network from
multiple types of attacks, including DoS and DDoS attacks that reduce the overall availability
of the system. Finally, an administrative model was defined to allow management secure
access to the production environment. One component not depicted in the above diagram is
the presence of an analytics model that observes when endpoint behaviour may be
indicative of a compromise, or a flaw in the firmware or hardware design.
V1.1 Page 26 of 43
8.6 Summary
Overall, this simple technology could have been easily compromised had it been deployed
as is. Yet, with a few fast, simple, and cost-effective changes made on the endpoint, the
technology is assured to have years of longevity in the field without change to the
architecture.
With the service ecosystem ramped up, there is far less of a threat to both users and the
business. Cloning and impersonation is no longer a threat. Privacy is ensured by granting
each endpoint unique cryptographic tokens. Systems that contain critical information are
separated and secured from more heavily abused public-facing systems. This model, while
slightly more complex, reduces the overall risk of the production environment.
9 Example Personal Drone

In this example, a small personal drone device will be evaluated using this set of guidelines.
The endpoint will be assessed using the Endpoint Ecosystem document, while the service
side of the design will be assessed using the Service Ecosystem document.

A Drone and its Primary Components
This personal drone is composed of a robust set of components. The processing capabilities
of the drone are high performance due to the multiple motors, sensors, and other equipment
that all must function efficiently in parallel. This model uses an ARM Cortex-A8 CPU with the
primary operating system (Linux) stored in NVRAM on a separate chip. An array of various
sensors are required for detecting movement, light, speed, and more. A SD/MMC card is
used to store video, sensor metrics, and metadata. A camera is used to allow the operator to
see from the drones perspective. A cellular/GPS combination module is used to ensure the
drone can maintain connectivity to its operator even when it is out of range of a proprietary
protocol. GPS is also used for guidance, and for minimal automation.
V1.1 Page 27 of 43
A Lithium Polymer (LiPo) battery is used to drive the drone. Its fly time is approximately two
hours before a new charge is required when all functions are active at once.
According to the Endpoint Ecosystem document, this device would fit into the Complex
Endpoint class of devices. Even though it contains a cellular module, it is not considered a
gateway as it does not route messages to or from other endpoints.

From a service perspective, the back-end is only used for operator connectivity when loss is
detected on the proprietary radio interface during flight. If the drone is in flight and the
cellular connection can be enabled, it will attempt to wait for its operator to connect via the
LTE network. If, however, it is unable to be controlled over LTE, it will attempt an automated
landing at the location where it last lifted off.
However, as the drone has some light automation features, it can be given coordinates and
a path to traverse while taking photos or short videos. These media files can be uploaded in
real time over LTE to the back-end service to show the operator its course and viewpoint
during automated execution.
Thus, a robust back-end service is required to ensure a high degree of service availability for
each drone that might connect to the system. Availability is also necessary for the high
bursts of network traffic required to transmit videos and high-resolution images over a
cellular link. There must also be a web interface that allows the operator to view media
uploads from a web browser.
Flow of Data to Back End Services
9.3 The Use Case

The business developing this technology intends the end user to use the drone for filming in
the wild. However, some of their customers have used the drone for filming scenes in
V1.1 Page 28 of 43
cinema, as the camera and stabilization capabilities of the drone are exceptional for the price
point. As a result, the drone will be used in expensive filming projects where intellectual
property and privacy are major concerns.

Endpoint identity
Trust anchor attacks
Software and firmware tampering
Secure remote management
Detecting compromised endpoints
Service impersonation
Ensuring privacy
Improving availability
The team reviewed the recommendations for each of the above issues, as suggested by
each relevant Frequently Asked Security Question section. The team then chose to
implement recommendations that were cost-effective improvements that ensured the
greatest amount of security.
In this example, the service infrastructure does not require a substantial change. This is
because the service infrastructure already had to be built out extensively to accommodate
for the bursts of traffic required in servicing the endpoint product. The architecture already
demanded a well formed and secure architecture simply to be able to scale effectively and
maintain availability of resources even when some services were incurring temporary faults.
However, the organization chose to investigate user privacy further as this has become a
primary point of contention for the businesss unexpected niche.
The endpoint infrastructure, however, requires a significant amount of changes. The

engineers realize that, according to the recommendations, they are at serious risk of abuse.
The following issues are acknowledged:
The bootloader is not properly validating the application prior to executing the
operating system kernel, leading to a risk of tampering
There is no TCB used to manage the security of the application or communications
Because there is no properly implemented TCB or trust anchor, endpoint
impersonation is a problem, which may lead to data leakage
Without a well implemented TCB, the endpoint cant properly authenticate services
V1.1 Page 29 of 43
Without a well implemented TCB, the endpoint cant properly authenticate the
operator over the proprietary radio interface
The engineers have relied on the security of LTE to ensure the communications
channel cant be compromised, but has not considered the threat of endpoint
impersonation or Femtocell repurposing, both of which bypass the security of LTE to
compromise weak service security
9.5 The Result

After implementing the recommendations for the issues cited above, the organization has a
much better defined endpoint architecture that adequately addresses the risks identified
through the guideline documents.
For the existing drone system already in production, the engineering team issues a firmware
update that implements a Personalized Pubkey security model. The firmware update
improves the bootloader as well to bake security into the core architecture. Since a
Personalized Pubkey model was used, anyone attempting to abuse the initial lack of security
in the endpoint to attempt to impersonate another users endpoint would fail, as the
engineers leveraged their existing user-to-endpoint mapping database to create
personalized keys on a per-user basis. This way, no user without the appropriate web
credentials can download and install another users Personalized Pubkey update. While this
process was complex and time consuming to implement, it will be worth the effort.
Future versions of the drone technology will implement an internal CPU trust anchor. This
trust anchor will be tied to a Personalized Pubkey TCB, to ensure that each endpoint is
uniquely seeded with exceptional security from the ground up.
Deploying strong cryptography in this fashion is imperative, as it also negates the potential
for the other classes of attack the company identified as a concern. By leveraging the benefit
of strong cryptography and a TCB for verification and authentication, the engineering team
can easily identify whether rogue services are being made available to the drone. The drone,
upon detecting rogue services, can simply land back at the original take-off site.
Any service that detects an improperly secured drone can also raise flags internally. The
administration team, at that time, can determine how to deal with the potentially
compromised drone. This provides a level of agility with regard to security events, and also
gives the organization a way to evaluate if there are software or hardware problems that are
causing abnormal behaviour on the endpoint.
9.6 Summary
While the engineering team obviously spent an exceptional amount of time creating a
resilient architecture from a mechanical engineering and back-end services perspective,
substantial work needed to be done to create secure endpoint technology. While this
scenario did not pose a critical threat to the overall business, it was fortunate that there was
a solution that worked well enough for their customers needs. Had this been a more safety-
critical technology, even the solution deployed here may have not been sufficient.
V1.1 Page 30 of 43
For more information on Trusted Computing Base variants, such as Personalized Pubkey
TCB or Personalized PSK TCB, please review the IoT Service [3] and Endpoint [4]
Ecosystem documents.
10 Example Vehicle Sensor Network

In this example, a vehicle sensor network deployed in a new class of automobile will be
evaluated using this set of guidelines. The endpoint will be assessed using the Endpoint
Ecosystem document, while the service side of the design will be assessed using the
Service Ecosystem document.

Full Vehicle Sensor Network and Communications System
While the above model is too complex to properly depict in a simple diagram, the three high-
level components involved are:
A telematics uplink unit that manages the sensor network, makes complex decisions
on behalf of the driver, and maintains a connection to the back-end system
A vehicle-to-vehicle (V2V) system that detects and reacts to V2V events
A general sensor network that provides metrics to the telematics uplink unit
In modern automotive systems, the telematics unit is a part of the automobiles computer
network and makes decisions based on sensor data and back-end communications. This
unit will make decisions with, or on behalf of, the consumer driving the vehicle. The unit
ensures that the vehicle is operating properly, attempts to make intelligent decisions during
emergencies, and takes commands from the back-end network.
The V2V sensor network identifies vehicles in the vicinity and makes decisions based on
metrics gathered from sensors. While the telematics unit primarily makes decisions based on
the state of components (such as brakes or tire pressure monitors) the V2V system makes
decisions based on the presence of other vehicles, or sends out alerts to nearby vehicles in
the case of a critical event.
V1.1 Page 31 of 43
The general sensor network is a series of components that provide data to the telematics
unit, and sometimes the V2V unit. These units use the information gathered from the general
sensor network to make accurate decisions during critical events.
According to the Endpoint Ecosystem document, this system has components that fit into
every IoT endpoint class. The telematics uplink unit acts as a gateway. The V2V unit acts as
a complex endpoint. The general sensor devices are effectively all lightweight endpoints.

From a service perspective, the vehicle sensor network will provide metrics to the back-end
environment. This data may or may not be provided to the consumer. Rather, the data could
be stored by the manufacturer to observe or identify potential problems with components.
This may trigger service warnings that are then issued to the consumer.
The system may also be augmented to provide the consumer with useful services, such as
remotely unlock door, start engine, and similar features. In the near future, these systems
may allow vehicles to be driven remotely through automated guidance systems.
While most critical decisions will be made in the processing units on the vehicle itself, it is
reasonable to conjecture that some decisions will be made in the cloud, where more
machine learning (ML) and artificial intelligence (AI) along with behavioural or statistical
models can be leveraged to make more complex decisions.
Flow of Data to Back End Services
10.3 The Use Case

The use case of this technology is obvious: to build smarter vehicles that can make complex
decisions in safety-critical scenarios. The goal is to leverage the intelligence of as many
sensors as possible to make critical decisions in very small windows of time. Automatic
breaking, tire blow-out broadcast alerts, temporarily disabled operator warnings, and other
V1.1 Page 32 of 43
critical scenarios can potentially be resolved through the use of sensors and well designed
computer systems.
One interesting feature of this technology is that it may be entirely transparent to the user.
The user would not need to configure these computers to act in a certain fashion. Instead,
they should be capable of negotiating the current landscape through the use of sensor
metrics. This will allow the computers to behave correctly regardless of the environment.

Service or Peer impersonation
Side-channel attacks
Detecting compromised endpoints
Ensuring safety at the risk of security
Identifying anomalous endpoint behaviour

The biggest risk to this environment that hasnt been discussed in previous examples is the
risk of impersonation with regard to peers. One concern that engineers have in this type of
environment is the risk that a computer will make critical decisions using data that is not
properly authenticated.
Since sensor data in critical scenarios requires exceptionally fast processing times, it is
theorized that it may not always be feasible to implement asymmetric cryptography or PKI
based communications. However, this may not be an accurate assertion. Instead, an
accurate security model should account ahead of time for time-critical scenarios and cache
session keys for nearby Endpoints. For example, if two objects are approaching each other
at a known rate, security applications in the Service Ecosystem can prepare session keys
specific to these two Endpoints before they reach a distance where they can physically
impact one another. This would ensure that secure communication between Endpoints and
sensors can still be used in the event that there is no time to renegotiate an instantaneous
secure session when the potential for a critical scenario (like an impending automotive
crash) is detected. .
Thus, an augmentation to the TCB implementation is required. One interesting solution is

GBA, where the UICC used in the telematics uplink unit can distribute keys securely to
endpoints throughout the system. This protocol will allow even rudimentary endpoints to be
seeded with secure session keys that can be used in multiple critical scenarios. This way,
the environment can always be seeded from a root of trust, even if lightweight endpoints are
not capable of critical maths for public key session initialization.
V1.1 Page 33 of 43
Another critical issue in these environments is detecting compromised endpoints. For

example, how can the environment recognize whether a simple sensor, such as a Tire
Pressure Monitor (TPM) has been compromised? If the computer makes a critical decision
based on the TPM signalling a tire has blown, a safety issue may arise. As a result, the
behaviour of devices, and their trustworthiness, must be reassessed at every boot-up phase.
All devices should have tamper resistance, and must be able to notify the network if there is
a compromise. Inversely, there should be a way that other devices in the sensor network can
evaluate the trustworthiness of peers in the network.
10.5 The Result

After implementing the recommendations, the vehicle sensor network is well guarded
against attacks on the vehicle communications network. GBA is used to distribute keys to all
endpoints in the system, and does so on every boot-up, ensuring that old keys are not
reused. This, along with tamper resistance, a strong TCB in every endpoint, and an
organizational root of trust, allows the environment to function with far less risk.
Yet, regardless of these changes, safety is still a critical factor. The engineering team and
business leadership, along with the companys legal team and insurance brokers, should
evaluate safety critical technology and determine whether security can be implemented
without risking safety of the users. While security can often be implemented, even in safety-
critical scenarios, with some architectural adjustments, there are times when safety must
come before all other concerns.
10.6 Summary
Systems like these are often well engineered and take a large amount of effort to attack the
ecosystem. However, subtle flaws in the communications architecture can lead to a
compromised environment. In walled gardens, such as some CANbus networks, a single
flawed endpoint can cause the entire system to become vulnerable. This, in safety-critical
environments, is unacceptable.
V1.1 Page 34 of 43
Annex A Recommended Privacy Considerations for IoT Service

providers
In order to build trust in the IoT ecosystem and minimise the need for formal regulatory
intervention, the GSMA proposes the following high-level steps as a guide to minimising any
privacy risks. We recommend that IoT Service Providers follow these steps and consider
these questions at the early development stages of their IoT service or product.
GSMA IoT Privacy by Design Decision Tree
Step Consideration
What data do you need to collect from / about the user so that your IoT service or
product can function properly?
One of the first steps in any business model relying on data is to identify what information
is actually required from or about the consumer, for the service or product to function
properly. The types of data a service requires could be categorised as static such as the
consumers name or home address and data that is dynamic, such as real-time
location. So if you are offering, for example, a fitness wristband tracking someones steps
Step 1 and calories burned, then you would need to know the weight, age, gender, distance
travelled and the heart rate of the individual wearing the wristband, but you would
arguably not need the actual location of the individual.
When assessing the types of data needed, its also important to decide whether the
individuals consent is needed to use that data and how you would obtain their consent or
indeed offer them options to control their privacy preferences. A smartphone could act as
a medium for offering the user privacy options (e.g. mobile app or online dashboard)
where the product itself has no screen.
V1.1 Page 35 of 43
Is the data personal and regulated in law?

The next step should be to identify the data protection and privacy requirements that the
law imposes on you. Questions to consider include:
What is the definition of personal data in the country/market concerned?
Is the data collected personal & regulated in law? If so, have you identified the legal
basis that allows you to process such data?
Step 2
Are you subject to any privacy-related licence conditions (e.g. as a telecoms
provider)
Are there any federal, state, local or sector-specific laws that apply in relation to your
proposed data collection model, in addition to general data protection laws? e.g.:
o Financial / payment services, healthcare regulations
o Potential restrictions on cross-border data transfers
How will data be used and what for?
Once you have established what your legal compliance requirements are, the next step is
to map out how the data you collect will be used and who they need to be shared with
to achieve intended outcomes as part of your service offering. The following questions
should help you address both security and privacy considerations in relation to the
treatment of the data:
Is the data kept secure both when stored and transmitted?
Have you clearly set out the data flows? I.e. identify how the data will be used and
shared across the value chain and for what purposes
Step 3
Can you justify why each type of data collected is needed in the specific context of
offering the intended service?
Have you defined/agreed privacy responsibilities with your partners from the outset
(and does your product design reflect these responsibilities?)
Are there appropriate contractual agreements in place with the companies you are
sharing consumers data with? (E.g. limiting the use of data by analytics providers
for their own commercial purposes). Such agreements or restrictions can be bi-
lateral or you could establish a code of conduct or guidelines and ask your partners
to commit to them with defined consequences and liabilities if they fail to do so.
V1.1 Page 36 of 43
Conduct a Privacy Impact Assessment

Conducting a Privacy Impact Assessment (PIA) is about:
Identifying what, if any privacy risks your product or service raises for individuals.
Reducing the risk of harm to individuals that might arise from the possible misuse of
their personal information
Designing a more efficient and effective process for handling data about individuals
PIA requirements are increasingly becoming common in data protection and privacy laws.
There are a number of guides on how to conduct a PIA including those published by the
Step 4 UKs Information Commissioners Office [10] and those by the International Association of
Privacy Professionals.
Typical questions to be addressed when conducting a PIA include:
Will the project result in you/your partners making decisions or taking action against
individuals in ways that can have a significant impact on them?
Is the information about individuals of a kind particularly likely to raise privacy
concerns or expectations? For example, health records, criminal records or other
information that people would consider to be private?
Will the project require you to contact individuals in ways that they may find
intrusive?
Design Privacy into the User Interface
After assessing the privacy risks to the consumers, you should consider how to raise
those consumers awareness of such risks and how to mitigate them as well as offer them
options to express their privacy preferences. Ultimately, this step is about ensuring you
offer a service that meets your legal obligations and the consumers needs and
expectations in a user friendly way. And its about building their trust by reassuring them
that they have more control over their privacy. Questions to consider include:
How can consumers be made aware of any risks to their privacy and how can they
make informed choices?
Step 5 Have you obtained their consent, where legally required? Key elements of consent
include: disclosure, comprehension, voluntariness, competence, and agreement)
Is data secured in transit and at rest?
Is there a set period for which you need to keep consumer data (and why)?
Does the consumer journey help gain their trust? For example:
o Do they understand what data they are sharing in return for using the
service?
o Can consumers express their privacy preferences in simple steps e.g. via
a web based permissions dashboard, just-in-time prompts, a call
centre, a mobile app, a voice activated command etc.
V1.1 Page 37 of 43
Could the use of data impact an individuals privacy?

Your product or service may collect data that are not necessarily classified as personal
in law but may still have privacy implications to the consumer and should therefore be
considered early on. To ascertain whether the relevant data could be used to impact a
consumers privacy consider the following:
Could (non-personal) data from your service/product be combined with other data
from different sources to draw inferences about a consumers personal life? For
example inferences about his/her lifestyle, habits or religion that would:
o Affect his/her ability to get health insurance?
o Be used by 3rd parties (retailers, insurance companies) to price
discriminate against the specific consumer?
If your product or service is likely to change at any point in the future what are the
likely privacy implications of any such change on the consumer. For example:
o Does the change involve the collection of new data about the consumer
(such as location data)?
Step 6
o Are existing or new consumer data shared or sold to third parties (e.g.
advertisers) who would start using consumer data for different purposes
than those originally obtained for?
If any such changes occur you should:
o Check the possible impact on your business if new laws are invoked as a
result of the change
o Establish processes to inform the consumers and obtain their consent
where necessary
o Provide the means for consumers to change their privacy preferences
Some additional considerations that we recommend IoT service providers consider
are:
o Make sure you have appropriate contractual agreements in place
defining the responsibilities of each partner in the value chain
o Have a clear process of redress so that the consumers know who to turn
to if things go wrong or if they suffer from a privacy breach
The following diagram presents one option of how the proposed steps above could be
illustrated:
V1.1 Page 38 of 43
Annex B Example based upon Automotive Tracking System

In this example, an automotive tracking system will be evaluated from the perspective of the
IoT Security Guidelines. The process will stem from section six of this Overview document
Using This Guide Effectively.
B.1 Evaluating the Technical Model

In the first step, Evaluating the Technical Model, the engineering team assesses how the
device functions based on their products architecture. The engineering team creates a
document that itemizes the technologies used in the solution in order to organize personnel,
assign Security Tasks, and track progress.
For the sake of simplicity, our automotive tracking system will have the following capabilities:
Endpoint Ecosystem:
A simple Graphic User Interface (GUI) that allows a user to:
Log in with a username and password
Disable tracking
Enable tracking
Identify and visualize current location
A cellular module for connecting to back-end services
A SIM card for the cellular module
A Lithium-Polymer battery for back-up power
A Central Processing Unit (CPU)
An embedded application in Non-Volatile RAM
RAM
EEPROM
Service Ecosystem:
Cellular Data connectivity
Secure Private APN
Service Access Point
Cellular Modem OTA management service
SIM Card OTA management service
After marking down the information relevant to each technology, the team reviews the Model
section of each Guideline document and identifies the appropriate technological model. This
Endpoint is a Complex Endpoint. The Service and Network model is a standard mobile-
enabled IoT service.
B.2 Review the Security Model

With the technical model outlined, the organization should now be ready to move forward
with the review of the security model. In the security model, the team will evaluate how an
adversary is likely to attack the solution.
V1.1 Page 39 of 43
Connected Car Attack Surfaces
In our example solution, there are only two threat surfaces that are relevant to an attack:
The cellular network

A localised attack on the vehicle
Since there is no local network connection, only a mobile network connection, an Attacker
would have to either compromise the cellular network connection, enter the communications
channel from the private APN or enter via the Service Access Point, cellular modem OTA
management server or SIM card OTA management server.
Physical attacks are the only other way to compromise the device of which there are multiple
entry points as shown in the above diagram, so in the case of this IoT service the Endpoint
should be heavily focused on.
B.3 Review and Assign Security Tasks

With the security model evaluated it is now simple to assign Security Tasks. Each team
should assign a specific person to each Component of the solution that needs evaluation.
This should be evaluated not only from the high level perspective (Endpoint, Network, and
Service) but from the subcomponent perspective. This means that the CPU should be
assigned a worker, the operating system, the network service, and so forth.
Once each Component is assigned to an owner, the process can begin. This means, at this
stage, the team understands:
How the technology is composed

What technologies affect security
What engineering stakeholders own the given technology
V1.1 Page 40 of 43
B.4 Review Recommendations

In the recommendation review phase, each member of the team should read and
understand as many of the recommendations as possible. This is by design. Instead of
focusing solely on the recommendations affixed to a specific Component, engineers should
take the time to understand as many recommendations as they are able, even if only at a
high level, to gain a better view of how their Component affects the overall security of the
product or service. This way, the group can engage in valuable discussion on what
remediation or mitigation strategies will have the most balance from a cost effectiveness,
longevity, and management perspective.
Once the recommendations are reviewed, the Component owners can determine whether a
recommendation has already been applied, or mark a recommendation pending. This will
allow the group to have a discussion regarding the applicability of a recommendation prior to
its deployment. This is a better strategy to follow, as some recommendations may have side
effects that impact the fulfilment of other recommendations, or existing controls.
In this example, the team would have determined that:
An application trust base should be used

An Organizational Root of Trust should be defined
Device personalization should be implemented
Tamper resistant casing should be implemented
Endpoint password management should be enforced
Endpoint communications security should be enforced
Cryptographically signed images should be implemented
Privacy management should be implemented
Device power alerts should be integrated
B.5 Review Component Risk

Next, the Components section should be evaluated to identify the various risks involved in
implementing or integrating a particular Component into the product or service. This section
can generally be reviewed only by the Component owner to minimize work. Though, it is
always beneficial to read as much as possible.
After reviewing Recommendations and the Component risk section, the following security
gaps were identified:
Secrets were stored unprotected in EEPROM

Secrets were not processed in internal RAM
User interface must protect passwords
User privacy should be outlined for the user
B.6 Implementation and Review

Now the team can adjust the solution to adhere to the security requirements they agreed
upon. The team re-implements components, where necessary, and adds security controls,
where necessary.
V1.1 Page 41 of 43
In this particular instance, the team has identified that they are working with a GSMA
member that is capable of provisioning an SIM card that contains application-capable trust
anchor technology. They will resolve their need for a trust anchor by using the existing SIM
card. This also resolves personalization, as each SIM can be personalized in the field using
standard GSMA technology.
SIM technology can also help provision communication security keys over the air, resolving
the need to implement communications authentication and privacy.
The SIM company-specific zone can be programmed with a trusted root base that enables
the business to authenticate peers using a certificate chain. This resolves Organizational
Root of Trust and peer authentication requirements.
The product encasing is updated with an appropriate tamper-resistant package.
The EEPROM is encoded with data that is encrypted with security keys stored in the SIM
trust anchor.
The bootloader is altered to use the trust anchor for the authentication of the application
image.
The Endpoint is reprogrammed to support secure password input from the user by blocking
out password characters as they are typed.
A privacy management GUI is added so the user can view and control what information is
being gathered by the business.
Secrets are processed only in internal memory of the same chip.
Once these implementations are defined, the team re-evaluates all security
Recommendations and Risks, and reviews the Security Model to identify whether the
changes have resolved their concerns.
B.7 Ongoing Lifecycle

Now that the team has achieved an approved configuration, they are ready to deploy their
technology. However, security does not stop here. The team negotiates a methodology for
monitoring Endpoints for security anomalies, and a methodology for identifying whether the
technology they are using contains newly discovered security gaps.
The team will plan how each incident or gap is identified, remediated, and recovered from.
This will ensure that, over time, the evolving technological and security landscape will not
take the organization by surprise.
V1.1 Page 42 of 43
Annex C Document Management
C.1 Document History

Version Date Brief Description of Change Approval Editor /
Authority Company
1.0 08-Feb-2016 New PRD CLP.11 PSMC Ian Smith
GSMA
&
Don A. Bailey
Lab Mouse Security
1.1 07-Nov-2016 References to GSMA IoT Security PSMC
Ian Smith
Assessment scheme added.
GSMA
Minor editorial corrections.
C.2 Other Information

Type Description
Document Owner Internet of Things Programme
Contact Ian Smith - GSMA
It is our intention to provide a quality product for your use. If you find any errors or omissions,
please contact us with your comments. You may notify us at prd@gsma.com
Your comments or suggestions & questions are always welcome.
V1.1 Page 43 of 43
Official Document CLP.12 - IoT Security Guidelines for IoT Service Ecosystem
IoT Security Guidelines for IoT Service Ecosystem

Version 1.1
07 November 2016

Copyright Notice
Disclaimer
Antitrust Notice
V1.1 Page 2 of 61
Table of Contents
1 Introduction 5
1.1 Introduction to the GSMA IoT Security Guideline Document Set 5
1.4 Definitions 6
1.5 Abbreviations 8
1.6 References 8
2 The Service Model 9
3 The Security Model 12
3.1 Networking Infrastructure Attacks 14
3.2 Cloud or Container Infrastructure Attacks 15
3.3 Application Service Attacks 17
3.4 Privacy 17
3.5 Malicious Objects 17
3.6 Authentication and Authorization 18
3.7 False Positives and False Negatives 18
4 Frequently Asked Security Questions 19
4.1 How do we Combat Cloning? 19
4.2 How Are Users Authenticated via the Endpoint? 19
4.3 How can the Service Identify Anomalous Endpoint Behaviour? 20
4.4 How can the Service Restrict an Abnormally Behaving Endpoint? 21
4.5 How Can I Determine Whether a Server or Service Has Been Hacked? 21
4.6 What Can I Do Once A Server Has Been Hacked? 22
4.7 How Should Administrators Interact With Servers and Services? 22
4.8 How Can the Service Architecture Limit the Impact of a Compromise? 22
4.9 How Can The Service Architecture Reduce Data Loss During a
Compromise? 23
4.10 How Can the Service Architecture Limit Connectivity from Unauthorized
Users? 24
4.11 How to Reduce the Likelihood of Remote Exploitation? 24
4.12 How Can the Service Manage User Privacy? 25
4.13 How Can a Service Improve Its Availability? 25
5 Critical Recommendations 26
5.1 Implement a Service Trusted Computing Base 26
5.2 Define an Organizational Root of Trust 27
5.3 Define a Bootstrap Method 28
5.4 Define a Security Infrastructure for Systems Exposed to the Public Internet 29
5.5 Define a Persistent Storage Model 30
5.6 Define an Administration Model 31
5.7 Define a Systems Logging and Monitoring Approach 32
5.8 Define an Incident Response Model 33
5.9 Define a Recovery Model 34
5.10 Define a Sunsetting Model 35
V1.1 Page 3 of 61
5.11 Define a Set of Security Classifications 35

5.12 Define Classifications for Sets of Data Types 36
6 High-Priority Recommendations 38
6.1 Define a Clear Authorization Model 38
6.2 Manage the Cryptographic Architecture 38
6.3 Define a Communications Model 40
6.4 Use Network Authentication Services 41
6.5 Provision Servers Where Possible 42
6.6 Define an Update Model 43
6.7 Define a Breach Policy for Exposed Data 43
6.8 Force Authentication Through the Service Ecosystem 44
6.9 Implement Input Validation 45
6.10 Implement Output Filtering 46
6.11 Enforce Strong Password Policy 47
6.12 Define Application Layer Authentication and Authorization 49
6.13 Default-Open or Fail-Open Firewall Rules and System Hardening 49
6.14 Evaluate the Communications Privacy Model 50
7 Medium-Priority Recommendations 52
7.1 Define an Application Execution Environment 52
7.2 Use Partner-Enhanced Monitoring Services 53
7.3 Use a Private APN for Cellular Connectivity 53
7.4 Define a Third-Party Data Distribution Policy 55
7.5 Build a Third-Party Data Filter 55
8 Low-Priority Recommendations 57
8.1 Rowhammer and Similar Attacks 57
8.2 Virtual Machine Compromises 57
8.3 Build an API for Users to Control Privacy Attributes 58
8.4 Define a False Negative/Positive Assessment Model 58
9 Summary 60
Annex A Document Management 61
A.1 Document History 61
A.2 Other Information 61
V1.1 Page 4 of 61
1 Introduction
1.1 Introduction to the GSMA IoT Security Guideline Document Set

This document is one part of a set of GSMA security guideline documents that are intended
to help the nascent Internet of Things (IoT) industry establish a common understanding of
IoT security issues. The set of non-binding guideline documents promotes methodology for
developing secure IoT Services to facilitate security best practices are implemented
recommended that the overview document CLP.11 IoT Security Guidelines Overview
Document [1] is read as a primer before reading the supporting documents.
CLP.11
Document CLP.14
IoT Security
CLP.12 CLP.13
+ Guidelines for
Network
Ecosystem Ecosystem
Figure 1 - GSMA IoT Security Guidelines Document Structure


V1.1 Page 5 of 61

This guide shall be used to evaluate all components in an IoT product or service from the
Service Ecosystem perspective. The Service Ecosystem includes all components that make
up the core of the IoT infrastructure. Components in this ecosystem are, for example,
services, servers, database clusters, network elements, and other technologies used to drive
the internal components of any product or service.
The scope of this document is limited to Recommendations pertaining to the design and
implementation of IoT services and network elements.
This document is not intended to drive the creation new IoT specifications or standards, but
will refer to currently available solutions, standards and best practice.
Backwards compatibility with the Network Operators existing IoT Services should be
maintained when they are considered to be adequately secured.

IoT Service Providers - Enterprises or organisations who are looking to develop new
IoT Endpoint Device Manufacturers - providers of IoT Endpoint Devices to IoT
Service Providers to enable IoT Services.
IoT Developers who build IoT Services on behalf of IoT Service Providers.
Network Operators who provide services to IoT Service Providers.
1.4 Definitions
Term Description
Access Control List A list of permissions attached to a computing object
Identifier of a network connection point to which an endpoint device
Access Point Name attaches. They are associated with different service types, and in
many cases are configured per network operator.
A hacker, threat agent, threat actor, fraudster or other malicious threat
to an IoT Service. This threat could come from an individual criminal,
organised crime, terrorism, hostile governments and their agencies,
Attacker
industrial espionage, hacking groups, political activists, hobbyist
hackers, researchers, as well as unintentional security and privacy
breaches.
A network of remote servers on the internet that host, store, manage,
Cloud
and process applications and their data.
A technology that makes it possible to run multiple isolated systems, or
Container
containers, on one host.
V1.1 Page 6 of 61
Term Description
A UICC that supports remote provisioning of the network or service
Embedded UICC (eUICC)
subscriptions it authenticates, as specified by GSMA.
End Customer Means the consumer of the IoT Service provided by the IoT Service
Provider. It is feasible that the End Customer and IoT Service Provider
could be the same actor, for example a utility company.
Endpoint Ecosystem Any configuration of low complexity devices, rich devices, and
gateways that connect the physical world to the digital world in novel
ways. See CLP.11 [1] for further information.
Forward Secrecy A property of secure communication protocols: A secure
communication protocol is said to have forward secrecy if compromise
of long-term keys does not compromise past session keys.
The Internet of Things describes the coordination of multiple machines,
devices and appliances connected to the Internet through multiple
networks. These devices include everyday objects such as tablets and
Internet of Things
consumer electronics, and other machines such as vehicles, monitors
and sensors equipped with machine-to-machine (M2M)
communications that allow them to send and receive data.
A generic term for a complex IoT endpoint device or IoT gateway
IoT Endpoint
device.
Any computer program that leverages data from IoT devices to perform
IoT Service
the service.
The set of services, platforms, protocols, and other technologies
IoT Service Ecosystem required to provide capabilities and collect data from Endpoints
deployed in the field. See CLP.11 [1] for further information.
Enterprises or organisations who are looking to develop new and
IoT Service Provider
innovative connected IoT products and services.
The operator and owner of the communication network that connects
Network Operator
the IoT Endpoint Device to the IoT Service Ecosystem.
A set of cryptographic policies and procedures that govern how
Organizational Root of
identities, applications, and communications can and should be
Trust
cryptographically secured.
Acts as a virtual firewall that controls the traffic for one or more virtual
Security Group
server instance.
A Trusted Computing Base (TCB) is a conglomeration of algorithms,
policies, and secrets within a product or service. The TCB acts as a
module that allows the product or service to measure its own
trustworthiness, gauge the authenticity of network peers, verify the
integrity of messages sent and received to the product or service, and
Trusted Computing Base
more. The TCB functions as the base security platform upon which
secure products and services can be built. A TCBs components will
change depending on the context (a hardware TCB for Endpoints, or a
software TCB for cloud services), but the abstract goals, services,
procedures, and policies should be very similar.
A Secure Element Platform specified in ETSI TS 102 221 that can
support multiple standardized network or service authentication
UICC
applications in cryptographically separated security domains. It may be
embodied in embedded form factors specified in ETSI TS 102 671.
V1.1 Page 7 of 61
Term Description
Secured and logically separated partition of a network to allow
dedicated usage by one particular customer set of service. So called
Virtual Private Network
because the VPN is Private from the rest of the network, and hence
acts as a virtualised network in its own right
1.5 Abbreviations
Term Description
ACL Access Control List
CERTS Computer Emergency Response Teams
DDoS Distributed Denial of Service
HSM Hardware Security Module
IP Internet Protocol
SQL Structured Query Language
TCB Trusted Computing Base
VM Virtual Machine
VPN Virtual Private Network
WAF Web Application Firewall
1.6 References
[1] CLP.11 IoT Security Guidelines Overview Document
[2] CLP.12 IoT Security Guidelines for IoT Service Ecosystem
[3] CLP.13 IoT Security Guidelines for IoT Endpoint Ecosystem
[4] CLP.14 IoT Security Guidelines for Network Operators
OWASP Secure Application Design Project
[5] n/a
https://www.owasp.org
TCG Trusted Platform Module
[6] n/a
http://www.trustedcomputinggroup.org
TCG Guidance for Securing IoT
[7] n/a
http://www.trustedcomputinggroup.org
OAuth 2.0
[8] n/a
http://oauth.net/2/
OpenID Foundation
[9]
http://openid.net/foundation/
V1.1 Page 8 of 61

[10] Not Used Not Used
GSMA Mobile Connect
[11] n/a
https://mobileconnect.io/
GPC_SPE_034 GlobalPlatform Card Specification
[12]
www.globalplatform.org/specificationscard.asp
GPD_SPE_010 GlobalPlatform TEE Internal Core API Specification
[13]
www.globalplatform.org/specificationsdevice.asp
[14] CLP.17
2 The Service Model

Modern IoT products and services require a Service Ecosystem to provide meaning,
functionality, and value to Endpoints, Partners, and Users. Depending on the complexity of
applications made available by the IoT offering, the infrastructure may be vast and
composed of many disparate types of services and service access points. Alternatively, the
infrastructure may be rudimentary for more straight-forward applications.
Regardless of the format, the Service Ecosystem acts as the nexus of functionality and
communication for each core facet of the overall IoT technology. All other ecosystems are
dependent on the Service Ecosystem for hierarchical authentication, connectivity to users,
availability, management, and other tasks critical to the day-to-day operation of IoT. To
accomplish these tasks, the Service Ecosystem is composed of any number of tiers required
to fulfil the goals of the infrastructure. Database clusters, application servers, application
proxy servers, and other types of infrastructure are example tiers that would be found in
many given deployments. As implied in the diagram below, the Network and Endpoint
Ecosystems are dependent on the core functionality of the Service Ecosystem.
V1.1 Page 9 of 61
Figure 2 - Dependencies Hinged on the Service Ecosystem
Some examples of modern Service Ecosystems include, but are not limited to:
Cloud Infrastructure based solutions

Container based application deployments
Traditional datacentre server environments
Database clusters
Web application framework service clusters
While each of these sample environments might seem widely variant in their design,
topology, and implementation, they are based on the same theories regarding how
information flows in and out of an application.
All modern computing systems require a point of entry, known as a service access point, into
an applications infrastructure. The internal subsystems that create content and context for
that application must be able to process data from within secure, reliable environments and
networks. Data must be stored somewhere, then returned to the service layer which
responds or sends authorized commands down to various components within the same
ecosystem, or other ecosystems and their associated networks.
V1.1 Page 10 of 61
Figure 3 - Sample Service Ecosystem
Regardless of what technologies, modern or traditional, are used to implement this standard
framework, information will be processed, served, and authenticated using proven protocols
and technologies. While topologies and abstractions for processing environments have
subtly changed to fit with modern requirements for speed, computational power, and
storage, the technologies used to implement these innovations are, at their core, the same.
For example, each tier typically contains a proxy or firewall system that manages
connectivity to and from a set of servers of a specific type. Billing services will reside in a
Billing Tier. Application Servers reside in a tier specific to the application. Database services
must be managed within a Database Tier. These systems all work together based on the
ingress and egress rules that are applied at the proxy servers.
As a result, the security model for the Service Ecosystem can be easily broken down into a
set of components. These components will be discussed in this document.
V1.1 Page 11 of 61
3 The Security Model

Security in Service Endpoint environments can be designed using common pieces of
infrastructure, strategies, and policies, regardless of the topology or innovations used to
build an application architecture. Each aspect of the Service Ecosystem can be broken down
into components. These components must be secured individually, but using similar
methodologies.
For example, consider the common components in building a simple service that is capable
of fielding queries and sending responses from and to endpoints, partners, and users. This
model should contain, but not be limited to, the following tiers:
A Web Service Tier

An Application Server Tier
A Database Tier
An Authentication Tier
A Network Tier
Third party application tiers, such as a Billing tier
Figure 4 - An Example Service Ecosystem with Separate Tiers.
Even if there is only one server in each tier, it is more architecturally effective to separate
each logical concept into its own tier. This also helps isolate one layer of technology from
other layers in the event of a compromise, or if the system needs to scale up to serve more
requests.
If a type of system is thought of from the perspective of a type of tier, it can be more easily
secured, scaled on-demand, decommissioned and sunsetted. The only requirement is an
V1.1 Page 12 of 61
API that is versatile enough to be augmented or adjusted throughout the lifespan of the tier.
Defining this API is out of the scope of this document. However, recommendations regarding
high level security attributes of the API the organization either chooses or defines will be
discussed here.
Figure 5 - An Application Tier Guarded by Firewall Technology
In the example above, a slightly more complete tier description is provided. The only
augmentation that is needed to depict the tier is a proxy server. This proxy server is just a
descriptor representing the actual security technology that will be employed within the tier.
Regardless of whether the actual control is a hardware firewall, software firewall, Security
Groups, Access Control Lists (ACL), or another technology, there will be a component that
mandates ingress and egress controls on behalf of the tier.
When choosing or defining an API, the organization should consider existing specifications
that may resolve the concerns of the engineering team. The organization should consider
the following specifications:
ETSI M2M TS 102 690

ETSI M2M TS 102 921
3GPP TS 33.220 (GBA)
For publicly accessible components, like the Service Front-End Tier, the only augmentation
the model needs is an additional security component for:
Distributed Denial of Service (DDoS) protection

Load balancing
Redundancy
Optional Web Application Firewall (WAF) capability
The above technologies should be implemented for any service to function properly, and to
ensure that the service they protect is made available even in the most resource constrained
environments. Defining these components is out of the scope of this document, but can be
further investigated by referring to the following entities:
V1.1 Page 13 of 61
The Cloud Security Alliance

NIST Cloud Computing Standards
FedRAMP
Cisco Network Management Guidelines
Other attributes required for the tier to function securely is the definition of the server, itself.
This is defined by administrative, application, and operating system controls internal to the
platform chosen by the engineering team.
While not exhaustive, a list of issues internal to the platform environment will be:
Logging to a centralized log service

Administrative Authentication and Authorization
Communications security enforcement
Data backup, restoration, and duplication
Separation of application duties
System Monitoring and Integrity
3.1 Networking Infrastructure Attacks

Adversaries attempting to compromise the Service Endpoint from the network perspective
will presume that there are weaknesses in the way entities communicate, and vulnerabilities
in services exposed through service access points. These attacks presume a privileged
position on the network equates to a position of power over the communications channel.
Figure 6 - An Example "Man In The Middle" Attack Model
The most common form of attack in this model is the Man-In-The-Middle (MITM) attack. This
attack presumes that there is either no peer authentication, one-sided peer-authentication, or
broken mutual authentication on the communications channel. An adversarys goal is to
impersonate one side of the conversation to force the peer to perform actions on the
adversarys behalf. This attack can be mitigated by enforcing mutual authentication, which
requires a well-defined Organizational Root of Trust, a Trusted Computing Base (TCB), and
a communications model.
V1.1 Page 14 of 61
Other attacks are, for example, attacks against Forward Secrecy, encryption
communications analysis, and side-channel attacks. These must be mitigated using proper
cryptography protocols, algorithms, and standards.
These attacks are difficult and require access to networking infrastructure either internally to
an organization, in the core Internet infrastructure between an organization and its partners
or Endpoint Ecosystem, or at the infrastructure near Endpoints. The simplest and most
common attack is attempting to manipulate the network infrastructure of the Endpoint, such
as the Wi-Fi, Ethernet, or cellular network, to gain a position of privilege between the Service
and its peer.
Attacks against a single endpoints infrastructure are restricted to that endpoint, or the group
of endpoints available in that physical location. Attacks against core internet infrastructure
typically involve Border Gateway Protocol (BGP) hijacking, attacking a core router, or
abusing the Domain Name Service (DNS) infrastructure. These attacks would provide a
position of privilege more disassociated with a particular target, potentially allowing the
attacker to have access to target many systems at once. Attacks against internal networking
infrastructure require access to the internal network, which implies an insider attack or an
existing position of privilege inside a corporations environment, which may imply an already
deeper system compromise.
Regardless of which type of attack is utilized, this model is easy to mitigate using mutual
authentication, forward secrecy, and appropriate cryptographic protocols and algorithms.
Doing so will negate an attackers ability to abuse this infrastructure, or will skyrocket the
cost of this type of attack to a price point that is infeasible for the common attacker to
implement.
3.2 Cloud or Container Infrastructure Attacks

These attacks presume a position of privilege on the Cloud or Container infrastructure
environment. For example, if an adversary is able to compromise a Cloud service network,
they may have access to hosts running guest Virtual Machine (VM) systems. This would
allow the adversary to inspect and modify running VM systems. The adversary may have
specific targets in mind, or may have gotten lucky and compromised a Cloud service
provider just for the access to many different types of systems with valuable data.
V1.1 Page 15 of 61
Figure 7 - Example VM Attack Model
Another Cloud or Container infrastructure attack presumes that the adversary has control
over a VM on the same physical server as the target VM. The adversary may then use
several methodologies to compromise other VMs on a physical server. They could:
Use a vulnerability in the VM infrastructure to break out of a Guest into a Host system
Use a side-channel attack to infer secret keys from another Guest VM
Consume excessive resources on the physical server to force a target VM to migrate
to a physical server that the attacker has more control over
Regardless of the attack model utilized, there is little that a business can do to guard against
this risk. Instead, the Cloud service provider must implement adequate functionality to
reduce the probability that an attacker can subvert the Cloud or Container infrastructure.
One way to reduce this risk is to implement a Container based architecture that limits each
container to one specific user and a unique cryptographic identity. While this is a highly
resource intensive activity, and may incur additional cost, it will mitigate the ability for an
adversary to abuse the VM infrastructure, to gain access to multiple users or multiple
services at once.
While a position of privilege in a Cloud or Container environment is a critical threat to

applications executing in guest VMs, it takes a high degree of skill, time, and resources to
gain access to this position. Once access is acquired, the adversary must maintain it long
enough to identify which system contains the VM that is relevant to their interests.
Furthermore, they must be able to monitor or alter that VM without being detected by the
Cloud services providers incident subsystem. This may pose a significant challenge, and
should diminish the likelihood of a compromise.
However, it is notable that this type of compromise is largely undetectable by the guest VM,
or an application running on top of it. Thus, metrics may be gathered that reveal anomalies
in the behaviour of a particular Cloud VM or Container, but it may be extremely difficult to
V1.1 Page 16 of 61
identify whether or not a compromise actually occurred. This is because any adversary with
sufficient privilege at the host layer of the VM infrastructure would be able to manipulate the
guest to make it difficult for it to detect manipulation.
Attacks from guest to guest are exceptionally difficult to detect, even by the Cloud service
provider. It is important to note, however, that these attacks are largely theoretical in nature.
While side channel attacks are possible, whether they are practical is up for debate as these
attacks require a level of consistency in the underlying execution platform that is not
guaranteed in a real world environment. Furthermore, escalation attacks from guests to
hosts in a VM, container, or hypervisor environment are difficult to find and even more
difficult to exploit. This makes it much less likely that a vulnerability will result in exploitation
of a mass amount of guests, or a specific target.
Therefore, while this is a significant position of privilege for attackers, the likelihood of a
successful attack is low as the difficulty, cost, and opportunity make exploitation mostly
impractical.
3.3 Application Service Attacks

While application execution architecture discussions are largely out of scope with respect to
this document, it is important to note that this layer represents the greatest risk of an attack.
If the Service Ecosystem has been configured correctly, as is recommended in this guide,
attackers will migrate away from network infrastructure attacks to the application, itself.
The application presents the largest layer of complexity in any product or service, and
always contains the potential for an adversary to increase their privilege through multiple
tiers of technology. Therefore, while the goal of this document is to drive the focus of an
attack away from the network infrastructure, it is driving the focus largely to the one place
where success is far more likely.
To diminish the potential for attack, please review many of the well documented pieces of
literature on application security (for example the OWASP Secure Application Design Project
[5]), to implement the application execution architecture as securely as possible.
3.4 Privacy
While partner systems are designed to consume data/metrics or other user-centric
components to provide added value to the overall system, there is never a guarantee as to
the level of security implemented by the partner. Rather than simply pass information to a
third party, it is necessary to evaluate what types of data should be handed over, what the
tangible return should be, and how that information shall be protected.
Legal liability can be diminished through contracts and insurance clauses, however, losing
customers can occur due to a third partys failure. Rather than risking such a loss of
business, an organization should evaluate third party engineering teams to determine what
level of security they apply to their infrastructure, applications, and APIs. If the level of
security is not sufficient, it is recommended to look for alternative partners.
3.5 Malicious Objects

Third party systems are designed to present information or multimedia to consumers. One
obvious way to accomplish this is through advertising. Various types of files are complex in
V1.1 Page 17 of 61
their structure, and are difficult for software to parse correctly. Advertising networks are an
interesting channel for the distribution of malware. Content Distribution Networks (CDNs)
also represent potential channels for malware distribution. Any system that offers complex
multimedia types, or bundles of code (either web or executable) for the purposes of
rendering dynamic information, can traffic malware.
Therefore, it is imperative that the business evaluate the different types of technological
offerings that will be passed through a particular channel. The business must decide what to
allow and what is too excessive to hand off to their customers. For example, an advertising
firm may want to traffic Java code to client systems over a proxy service application offered
to partners by the IoT business. The business will need to decide whether the client systems
running on certain environments are more susceptible to attack from Java technology. If this
is found to be true, the business may want to disallow Java, but allow other technology, such
as Hypertext Mark-up Language (HTML) to pass through.
Since malware comes in many forms, ranging from polymorphous file types, to Adobe Flash,
Java, and multimedia exploits, there is no single uniform way to guarantee the end-users
safety. A simple solution would be for the engineering team to enforce a policy on what
technologies are used over their channels, and how their users will be impacted. Monitoring
subsystems can be put into place, as well as sandboxes, to ensure that any object rendered
on a client system is less subject to abuse.
3.6 Authentication and Authorization

Partners often offer services that are only specific to a subset of users. This may include
paid services that a user can optionally subscribe to. This also may represent a way that a
user can authenticate to the system, but by using credentials shared with a separate, well
known, technology, such as existing authentication APIs from network service providers,
social network infrastructure, and existing M2M or IoT management entities.
While these are excellent ways to share technology across platforms, engineers must
ensure that technology is not inadvertently consuming credentials that can be used to abuse
permissions not expressly granted to a third party service. For example, certain platform
APIs allow the constraining of permissions to a class that is either accepted or denied by the
user. This allows the user to tune the experience to one that is suitable for their specific
privacy needs. If the platform is unable to offer granular security permissions, then it should
list what technologies it does want access to.
It is necessary for the engineering team to request of their partners that the offering enable
granular permissions to ensure that revocation of a service does not inadvertently allow a
window of exposure of that users data that continues on even after the subscription is
revoked.
3.7 False Positives and False Negatives

While monitoring and logging services are exceptional ways to augment an existing security
infrastructure, they must be carefully evaluated for false positives and false negatives.
Because these systems only interpret data originating from various ecosystems within an IoT
product or service, and these systems are not developed by the in-house engineering team,
they can only offer artificial insight into an event. They may not however be able to
accurately distinguish whether an adversarial event is actually occurring.
V1.1 Page 18 of 61
As a result, it is important to gauge the IT and engineering teams to determine if a suspect

event is, in fact, attributable to malicious behaviour. This will help to negate the potential for
the monitoring team to disallow a legitimate users access to the system. If this process is
automated, and the process is incorrect, many users may be shut out of their legitimate
service due to a false positive that can be attributed to an anomaly in the client application or
infrastructure. When a critical event is occurring that is questionable, the IT and engineering
teams should take a look at the data to evaluate whether there is indeed an attack.
Additionally, engineers must be careful to model information acquired through analogue

channels. False positives and false negatives, especially in ecosystems where data must be
processed at exceptionally high rates, can have significant consequences if the application
doesnt properly evaluate the safest course of action in the event that the acquired data
cannot be entirely trusted. It is notable that with sufficient time, technology, and expertise, all
analogue data can be impersonated to a digital system.
4 Frequently Asked Security Questions

Service security is broken down into recommendations by priority in this document. But, for
practical use, it is more beneficial to evaluate recommendations from a practical starting
point. Engineers typically start building a list of recommendations based on a technological
or business-influenced goal. This section outlines common goals from an endpoint
perspective, and which recommendations are relevant toward achieving those goals.
4.1 How do we Combat Cloning?

Differentiating between valid devices manufactured by the IoT Service Provider and devices
that are reproductions or rip offs (clones) is a challenging feat. No IoT Service Provider
wants to provide services for unauthorized endpoints, as Service Providers have to pay for
the CPU time, bandwidth, disk storage, and other resources. The organization must pay
regardless of whether the device was manufactured by the IoT Service Provider or not.
Furthermore, the organization must be able to discern whether their endpoint architecture is
being subverted. This enables the organization to react to a device that has been cloned into
multiple instances of the same device. This could be done by an unscrupulous manufacturer,
or an adversary trying to impersonate a particular user.
Review the following recommendations for assistance on using the Service to combat
cloning:
Define an Organizational Root of Trust

Use Network Authentication Services
Force Authentication Through the Service Ecosystem
Define Application Layer Authentication and Authorization
4.2 How Are Users Authenticated via the Endpoint?

One of the most important concepts in IoT is the separation of endpoint authentication from
user authentication. An endpoint can be authenticated by its Trusted Computing Base, but
how the user is authenticated is a separate process that relies on the endpoints TCB for
V1.1 Page 19 of 61
communications security. What is most important about this abstraction is evaluating how
trustworthy the communications channel is for user authentication.
For example, if the trustworthiness of an endpoint is low because there is no endpoint TCB,
or a weak endpoint TCB implementation is used, the user authentication mechanism that
relies on endpoint software/firmware to run cannot be trusted. This means that any user
authenticating through an endpoint device cannot be considered authenticated.
From a different perspective, a well architected endpoint TCB can poorly authenticate the
end-user if the authentication scheme is easily bypassable. Thus, the service ecosystem
must rely on the endpoints trustworthiness as well as the authentication mechanisms
implementation to ensure the service ecosystem can make guarantees about whether the
correct user is logged into the system.
Consider the following recommendations for assistance in dealing with these complexities:
Implement a Service Trusted Computing Base

Define a Clear Authorization Model
Enforce Strong Password Policy
Define Application Layer Authentication and Authorization
4.3 How can the Service Identify Anomalous Endpoint Behaviour?

One of the most challenging aspects of managing endpoints in a distributed IoT network is
determining whether or not an endpoint is behaving in an abnormal fashion. This is not only
important from a security perspective, but from a reliability perspective. Often, anomalous
behaviour can be indicative of a problem with the firmware or hardware, and may be a sign
that the organization should prepare to remediate an unexpected problem. However, if the
behaviour is isolated into a part of the network that cannot be analysed by the IoT Service
Provider, these metrics will be lost, leaving the organization at far less of an advantage.
Resolving this issue requires the ability to inspect behaviour on the endpoint, the network
layer, and the service ecosystem. However, if the right infrastructure, services, and
partnerships are not built to gather these data points, the organization wont have the
information required to make a determination as to whether there is a problem, or whether a
problem is related to security or reliability.
Evaluate the following recommendations from the service ecosystem perspective:
Define a Security Infrastructure for Systems Exposed to the Public Internet

Define a Systems Logging and Monitoring Approach
Define a Communications Model
Implement Input Validation
Implement Output Filtering
Use Partner-Enhanced Monitoring Services
V1.1 Page 20 of 61
Use a Private APN for Wireless Connectivity

Define a False Negative/Positive Assessment Model
4.4 How can the Service Restrict an Abnormally Behaving Endpoint?

Once an endpoint is identified as behaving abnormally, the service should make decisions
as to what resources should be limited or restricted. This question is relevant to every layer
of the service infrastructure.
For example, a cellular-enabled endpoint that constantly connects to and disconnects from
the mobile network in a frantic loop should be forcibly disabled until the erratic behaviour is
resolved. Another useful example is a compromised endpoint that an adversary is using to
try and attack back-end services. In this scenario, the back-end services should disallow the
abusive endpoint from reaching the services at all.
How to handle each scenario is up to the IoT Service Provider, and depends on their
business goals, and how incidents should be handled. To assist with developing these
guidelines, consider the following recommendations:

Define an Incident Response Model
Define a Recovery Model
Define a Sunsetting Model
Define a Breach Policy for Exposed Data
Define a False Negative/Positive Assessment Model
4.5 How Can I Determine Whether a Server or Service Has Been Hacked?
While endpoint anomalies are more esoteric and require a vast amount of behavioural
analytics to catch a majority of attacks, the service ecosystem is more straight forward.
Services and servers are deployed within an environment that is tightly controlled by the IoT
Service Provider or their partners that manage the cloud or server infrastructure. Thus, the
organization and its partners can use readily available monitoring and diagnostic systems to
identify and contain potential problems.
Review the following recommendations for assistance:
Define an Administration Model

V1.1 Page 21 of 61
4.6 What Can I Do Once A Server Has Been Hacked?

When a server has been identified as compromised, the administration team needs to
resolve the issue as quickly and efficiently as possible. The complexity in doing so often
arises from determining what resources, information, and accounts have been put at risk. In
some poorly architected environments, the effects of a compromise are not often
quantifiable. Therefore, the organization must implement a plan to resolve the security
vulnerability and secure at-risk assets in the field, in parallel. Once the ecosystem and
vulnerability have been secured, the organization can proceed with a plan to rebuild the
affected technology.
Review the following recommendations for more info:

Define a Set of Security Classifications
Define Classifications for Sets of Data Types
4.7 How Should Administrators Interact With Servers and Services?

Development an administrative model that doesnt put the service ecosystem at risk is an
important part of the architecture of an IoT service. There are multiple layers of
administration, and each layer should be considered by the engineering and security teams.
For example, administrators that govern the server (regardless of whether a virtual, micro-
service, or uni-kernel architecture is used) must be able to interact with live servers through
a reliable and secure communications channel. Administrators that govern the web
application often interact with the application over the same web communications layer, but
through a speciality application embedded in the code.
Regardless of the administrative need, the interface should be restricted-access to limit the
ability for adversaries to interact with or abuse the technology. Consider the following
resources:

4.8 How Can the Service Architecture Limit the Impact of a Compromise?
One fascinating attribute of an IoT network is its unique ability to attach services to specific
consumers. In web services, each user must be given the ability to interact with the service
from any type of device or, potentially, from anywhere in the world. This is not true of IoT
technology. IoT technology typically requires a specific endpoint device to interact with IoT
services. Because of this difference, server ecosystem architects can leverage the one-to-
one relationship between endpoints and consumers to restrict an endpoints access to back-
end data.
V1.1 Page 22 of 61
Consider the scenario where an endpoint is pushing sensor metrics to a back-end service. In
a micro-service architecture, the service ecosystem may deploy a specific micro-service or
uni-kernel to handle a particular consumer. Using this architecture, the engineer can ensure
that the micro-service is provisioned only with the resources and access capabilities required
to deliver data and services specific to the individual consumer.
This means that if a service is compromised, and the endpoint is the only technology that
can communicate with that specific service, there is zero additional benefit to compromising
that service as the access gained from the compromise will be limited to the resources that
would already be available to the endpoint. In essence, there is a zero sum gain from the
attack.
Review the following recommendations for assistance:
Implement a Service Trusted Computing Base

Define a Bootstrap Method
Define a Persistent Storage Model
Provision Servers Where Possible
Define an Application Execution Environment
Virtual Machine Compromises
4.9 How Can The Service Architecture Reduce Data Loss During a
Compromise?
Another interesting attribute of IoT architecture is the reduction of data loss. This is similar to
how services can be isolated to a specific user. Data can also be isolated to a specific user
once the user has been authenticated. However, data storage cannot easily be implemented
on a per-user basis because of the expense of database and storage infrastructure.
Instead, unique tokens should be provisioned to services that then act on behalf of a specific
user within the storage infrastructure. This way, an attacker with access to the data storage
environment may be able to connect to the service, but should not be able to interact with,
retrieve, or alter user data other than the user that has been compromised.
From the perspective of the network layer, reducing the flow of traffic from the server
ecosystem out to the Internet is also a requirement. Egress controls force an adversary to
traffic intellectual property or customer data through specific channels. This can either
increase the difficulty of moving large amounts of data, or force it through communications
layers that can detect and cut off communication during incidents.
For more information, consider the following recommendations:
Define a Bootstrap Method

Define a Persistent Storage Model
V1.1 Page 23 of 61

Provision Servers Where Possible
Default-Open or Fail-Open Firewall Rules
4.10 How Can the Service Architecture Limit Connectivity from Unauthorized
Users?
A benefit of leveraging common IoT architectures is restricting the ability for unauthorized
Internet users to directly connect to back-end services. Most web applications do not have
this luxury, and must be available for public use. In IoT, however, because the endpoint is
the entity that must connect to a particular service, Virtual Private Network (VPN) can be
used to restrict who has access to back-end services. This can be implemented over
standard Internet protocols, or can be implemented using mobile services, such as the
Private APN. Review the following recommendations for more information:

4.11 How to Reduce the Likelihood of Remote Exploitation?

Remote exploitation of web applications and services is a constant concern from
infrastructure administrators. Ensuring that adversaries dont have a route into the internal
network, or simply to valuable resources, is a daily battle. The only way to reduce the
potential for adversaries to compromise the service ecosystem is to decrease the potential
targets into a manageable set of services that can be quickly and easily maintained. The
second most important augmentation to the architecture is the design of the underlying
architecture: the execution architecture, operating system configuration, deployment
toolchain, programming language security, and other options that define how securely an
application may run. These options can be the difference between an application crash and
an infrastructure compromise.
For more information on reducing the potential for remote exploitation, please see:

Define an Update Model
Rowhammer and Similar Attacks
Virtual Machine Compromises
V1.1 Page 24 of 61
4.12 How Can the Service Manage User Privacy?

As IoT Service Providers grow, they will invariably build partnerships with organizations that
will utilize consumer data in innovative ways. However, this data comes at a cost to the
consumers privacy. Consumers should have a right to determine what data is shared with
partners and how it will be used. Also, partners should be required to use the data in specific
ways. Authorization models can assist with this, but this implies a far larger discussion
around privacy, legal repercussions, business insurance, and more.
To start the discussion within your organization, please review the following
recommendations:

Define a Breach Policy for Exposed Data
Evaluate the Communications Privacy Model
Define a Third-Party Data Distribution Policy
Build a Third-Party Data Filter
Build an API for Users to Control Privacy Attributes
4.13 How Can a Service Improve Its Availability?

Denial of Service (DoS) attacks or Distributed Denial of Service (DDoS) attacks are so
commonplace in the modern Internet that every company should be prepared to face a
major attack of this class, and should be able to stay online even under prolonged attacks.
The reason why these attacks have become so commonplace is that they lack very little skill
to execute and the tools to implement such an attack are readily available online. In fact,
there are service online where a malicious party can pay an attacker to implement a DDoS
attack against a particular target.
As a result, entirely new models for the availability of services have been built to combat this
threat. Consider the following recommendations when building out the service ecosystem:

V1.1 Page 25 of 61
5 Critical Recommendations
When developing a secure endpoint, the following recommendations should always be
implemented. The following critical recommendations define a secure endpoint architecture.
Without these recommendations, the endpoint will have an incomplete security profile that
will be abused by an adversary.
5.1 Implement a Service Trusted Computing Base

A Trusted Computing Base (TCB) is a set of hardware, software, protocols, and policies. A
TCB must be the basis of any given computing platform, and must define the environment in
which an application can run reliably, securely, and with high quality.
A TCB can be built and deployed for any given class of system, such as Mobile Equipment
(smartphones), IoT Endpoints, and even servers living in a Service Ecosystem. TCBs are all
composed of similar technologies. Yet, depending on the class of system, those
technologies may take on very different characteristics. For example, bootstrapping a TCB in
a cloud server will look vastly different than bootstrapping an endpoint.
Building a TCB in a Service Ecosystem means defining the way an application image shall
be rolled out. An image in this context represents the raw binary data that comprises an
application executable, its configuration files, and its metadata. These things together are
commonly referred to as an application image, or simply image. In most modern Service
Ecosystems, systems will be replicated, powered up, or spun down on demand to reactively
scale with changes in the computing environment. This means that a TCB must define a way
to allow systems to scale effectively while maintaining a persistent security model.
To do this correctly, the team must:
Standardize the computing platform:

Choose a set of physical server models
Select a set of Cloud platforms or Virtual Machine (VM) images
Define the set of applications, libraries, and configuration files to be ran on the
computing platform:
Define a container environment, if applicable
Generate an application image, composed of the set defined above
Cryptographically sign an archive of the image using the Tier TCB Signing Key
Securely store the archive and the signature
Performing this set of tasks will result in an approved application image that can be deployed
in a specific tier. Each tier will have a different hardware and application model that works
best for that specific tier. For example, database hardware has vastly different performance
and storage needs than an application tier. A storage tier will have similar hardware storage
requirements as a database tier, but will have different performance requirements. After
standardizing each tiers definition, the result is an image that can be deployed and verified
on each hardware platform.
The difficulty in deploying a TCB comes from:
V1.1 Page 26 of 61
Setting up an Organizational Root of Trust to manage cryptographic signing of

images
Setting up a procedure for signing each image
Setting up a procedure for verifying each image
Setting up a procedure for rolling out images in an automated way, but with image
verification
Please consider using material from the following organizations to assist with this
recommendation:
GlobalPlatform Card Specification [12]

Trusted Computing Groups TPM Specification [6]
GlobalPlatform TEE Internal Core API Specification [13]
5.1.1 Risk
Without a well-defined Trusted Computing Base, computing platforms are unable to verify
that it is currently running in a configuration approved by the engineering team. This is
important as the application subsystem must be able to determine if it has been
compromised by an adversary. A TCB can be used to remediate this risk, as well as provide
a security layer for all network communications.
5.2 Define an Organizational Root of Trust

An Organizational Root of Trust is a certificate or public-key based system for authenticating
computing platform entities in an organization. Each computing platform in a Service
Ecosystem must be cryptographically authenticated during network communications. This
diminishes the ability for an insider, or someone within a privileged network position, to
impersonate or otherwise abuse the trust of a privileged system.
To build an Organizational Root of Trust, simply perform the following actions:
Build or acquire, for example, a Hardware Security Module (HSM) to store the
organizational root secret
Generate a root secret and/or certificate
Ensure the private facet of the secret is stored securely
Generate a set of one or more signing keys to be used for Tier TCB signing key
Sign the public facet of the signing key with the organizational root
Ensure these keys cannot be used without authentication and authorization from the
business and engineering leads
Every time a new Tier system is defined, its unique cryptographic key or certificate can now
be signed by the signing key. If another system connects to this new system, it can validate
the identity of the system by verifying the chain of trust defined by the organizational root.
It will cryptographically validate that the messages were signed by the public key
representing the system. Then, it will verify the signature the signing key generated of that
systems unique public key. Then, the client should verify that the signing key was indeed
the signing key authenticated by the organizational root.
V1.1 Page 27 of 61
Because each set of certificates or secrets is restricted to fewer and fewer individuals in the
organization, and the policies and procedures defined should restrict who can use those
secrets and when, each level of trust should increase as the client descends through the root
chain.
A service must be defined that presents authentication capabilities to authorized peers within
the Service Ecosystem. For example, authentication using the certificate or secret chain
cant be used on its own to guarantee security. A service must be made available that
verifies whether certificates have been revoked, or are currently valid. Another service may
need to be used to authenticate the identities of servers or services with a short lifespan,
depending on the requirements of the underlying infrastructure.
During the definition of the Root of Trust, consider that:
Each secret must be guarded from abuse

Internal use of each secret must be verifiably tracked and monitored
Each individual approved to utilize a secret must use multi-factor authentication when
accessing the secret(s)
Defining a set of policies and procedures that enforce consistent and secure usage
can be challenging
Building a process to sunset or revoke a certificate can be challenging
Identifying whether a key has been abused can be challenging
Choosing the correct set of cryptographic algorithms may be non-intuitive
For further reading on the Root of Trust concept, please consider the following sources of
information:
Trusted Computing Group

TPM Specification [6]
TCG Guidance for Securing IoT [7]
ISO 11889
PKI Specifications
RFC 2510
RFC 3647
5.2.1 Risk
The risk of not using an organizational root of trust is that any compromise to a single key
can result in compromise of the entire ecosystem. By separating the organization into a
hierarchy, and deploying separate keys for the hierarchy, keys can be cycled at regular
intervals and according to the priority of the application or sub-organization the key relates
to.
5.3 Define a Bootstrap Method

In order for an application to run properly, it must be loaded and executed in a consistent
way on a reliable, high quality, and secure platform. The TCB defines how to formulate this
platform, but the Bootstrap model defines how the application shall be ran on top of it.
To define a Bootstrap model effectively, the following must be considered:
V1.1 Page 28 of 61
Define an API that allows the application to cryptographically identify itself to its peers
Consider utilizing an existing API defined by a trusted industry leader
Define how the application will authenticate Endpoints, Service Peers, and Partners
Define what the applications configuration should look like
Enforce each different application to have a unique identity, especially applications
running on separate tiers
While it may seem intuitive that an application should cryptographically identify itself to its
peers, and it may not need an API to do so, the process in production is slightly non-intuitive.
This is because in the bootstrap model, one must consider how the cryptographic identity is
provisioned to the application. How does the application acquire its identity? Is the identity
acquired securely? What is the process for revoking secrets that the identity will use in the
event the secrets must be updated or altered?
At run-time, applications require certain resources to execute effectively. The application

must be able to communicate and perform mutual authentication with all external services,
endpoints, and partners that are involved in this process.
An applications configuration often determines how secure it is in production. A

configuration should be enforced, and presented read-only to an application. The
application, or someone abusing the application infrastructure, should not be able to simply
alter the configuration of an application.
Use the Organizational Root of Trust to define trust models for each Tier deployed in the
overall ecosystem. This will allow each separate application to have a unique cryptographic
identity. This will provide peers with the ability to differentiate between a database service
and an application service, for instance.
5.3.1 Risk
Without a well-defined Bootstrap Model, the system will have no way of verifying each layer
it requires to operate. In essence, there is no layering of trust on each facet of the overall
technology. This lack of trust layers introduces complexity that can result in gaps that may
be abused by adversaries.
5.4 Define a Security Infrastructure for Systems Exposed to the Public

Internet
For publicly accessible services, several pieces of security and reliability technology are
required to maintain the availability, confidentiality, and integrity of the service:
DDoS-resistant infrastructure
Load-Balancing infrastructure
Redundancy systems
Web Application Firewalls (optional)
Traditional Firewalls
These additional technologies should be placed in front of the applications tier to ensure that
it cant be manipulated by public attackers. While the communication security model will
V1.1 Page 29 of 61
remediate or mitigate the potential for an anonymous third party to access the system, these
technologies will diminish the ability for the adversary to make the system unavailable.
Front-end security should be applied to all protocols implemented by the services. For
example, if the service is available over IPv4 and IPv6, the same security constraints should
be applied to the service over both protocols. If a service is accessible over TCP as well as
Stream Control Transmission Protocol (SCTP), the security constraints should be applied to
both of those protocols as well. Ports that do not offer public services pinned to the IoT
product or service should not be accessible.
Ensure that both ingress and egress filtering are managed, whenever possible. While
ingress filtering stops a range of attacks, any attack against a publicly accessible service can
still result in a compromise of the service ecosystem. Egress filtering is imperative, at this
point, to ensure that a compromised component of the service ecosystem cannot be used by
an attacker to move laterally within the ecosystem. In addition, egress filtering helps to
complicate the ability for attackers to exfiltrate critical data from the ecosystem to adversary-
controlled servers, leaving more time for administrators to identify and isolate the attacker.
Several organizations offer these services in a simple API model that can be dropped into a
given technology. This allows the technology to be used with little effort. Not much
engineering effort is required beyond signing up and configuring the application within the
service providers system. Consult with your service provider to determine the best way to
implement their security technology for your environment.
recommendation:
Amazon Best Practices for DDoS Resiliency:

https://d0.awsstatic.com/whitepapers/DDoS_White_Paper_June2015.pdf
Arbor Networks DDoS Mitigation Best Practices:
https://www.arbornetworks.com/images/documents/Arbor%20Insights/AI_DDoSMi
tigation_EN2013.pdf
Cisco DDoS Defence Guide:
http://www.cisco.com/web/about/security/intelligence/guide_ddos_defense.html
5.4.1 Risk
Secure infrastructure for public-facing services and applications is imperative due to the
volatile nature of the Internet. Random DDoS attacks occur often, and for little reason. DDoS
services can be purchased in the underground market for several hundred dollars. Thus,
adversaries of the business, or a businesss customer, will not be the only perpetrator of
such attacks. Random attacks can occur just to see if it is possible to take a system down. It
is better to be prepared against such attacks to ensure that critical IoT services are not
unexpectedly brought down. Availability is a critical component of an IoT product or service.
5.5 Define a Persistent Storage Model

Application environments in modern computing are often ephemeral, such as Container
based systems, or Cloud environments. As a result, the storage allocated to these systems
V1.1 Page 30 of 61
is not large enough, nor designed to be made available long term, for the application to use
these technologies as persistent storage. In addition, these systems may be defined as on-
demand entities, and may have no semblance of centralization. In other words, there is no
way for the other systems to define which system has enough storage for persistent use.
This is why central storage systems are imperative, and why they must be carefully secured.
Since storage systems must be made accessible to any given temporary system in this type
of environment, any short-lived server or service that becomes compromised will have
access to a persistent storage entity (or Tier) that is used by many other servers or services.
This is often an effective way adversaries can laterally (or potentially, vertically) compromise
any given network.
To restrict this, each server or service should have access to persistent storage, but should
store information based on the application it represents, and, more importantly, the unique
Endpoint, Partner, or User that the application is acting on behalf of. The last part of this
point is the most essential point, as enforcing persistent storage access on behalf of a given
identity limits the short-lived server or services access to data.
In other words, an adversary that has compromised short-lived system can only affect the
data stored on behalf of the identity tied to that same short-lived system. If that system only
has access to a single identitys data, the adversary cannot use this systems compromise to
migrate laterally to other accounts. They are restricted to accessing information for that
single identity. This significantly limits the adversarys ability to leverage a vulnerability into a
significant exploit of the system.
5.5.1 Risk
If a secure persistent storage model isnt defined, there will be no architecture that enforces
unique per-user attributes to be securely separated from other assets. The result can be that
any compromise of a token that grants an adversary access to a storage device may result
in the compromise of multiple users data. A persistent storage model, however, can isolate
the compromise to one single user, or a single storage technology with encrypted data. In
either case, the scope of the compromise is significantly reduced, granting the organization
more time to react and combat the threat to both users and the business.
5.6 Define an Administration Model

Each system must be accessible by administration to troubleshoot and diagnose application
faults. This can be challenging in environments where services or servers are short-lived, if
an administrative model is not sufficiently designed.
To accomplish this, identify how the administrative team will communicate with each system
in each tier. There should be authentication boundaries, such as VPNs, that separate
disparate systems from each other. Ensure the administrative team must authenticate
through each tier.
Also, identify how the administrator will interact with the system. Can the system be
snapshotted, akin to a VM? Is a terminal used? Is a remote Secure Shell (SSH) used to
interact with the system? Are there APIs for monitoring and analysis of system metrics, such
V1.1 Page 31 of 61
as CPU usage, disk usage, and network usage? Can those be used to troubleshoot or
identify anomalies?
Regardless of the model, there are certain things that must be defined:
How administrators will authenticate to the environment

How administrators authenticating can be attributed to physical identities:
Using two-factor authentication (2FA)
How systems snapshots can be taken
How changes can be made and must be tracked
5.6.1 Risk
Environments without a well architected path for administrative access typically end up using
ad-hoc means to access systems in production. This often leads to administrative ports that
are open to public connectivity, or services that offer diagnostics, but are not restricted from
being used by third parties. A clear administrative model reduces the potential avenues
attackers can take to gain privileged access to critical IoT resources.
5.7 Define a Systems Logging and Monitoring Approach

Each system must be monitored to allow administrators and Information Technology (IT)
works to detect and diagnose anomalies. Monitoring must be performed at multiple
dimensions. For example, network monitoring at the infrastructure level helps diagnose
application attacks or DDoS against network components. Tier monitoring identifies whether
specific applications or pieces of infrastructure may have been breached. While system-level
monitoring defines whether individual applications, or application platforms, are being
attacked or have been compromised.
This obviously takes multiple levels of monitoring and consolidates the information into a
resource that can be streamed to an oversight team. There are several professional
applications that provide this technology, and convert the metrics into visual systems usable
for IT professionals and system engineers.
Anomalies that indicate adversarial behaviour may include, but are not limited to:
Increased network traffic

Increased network traffic in an odd direction (especially egress)
Egress network traffic from a resource that shouldnt need egress
Abnormal CPU utilization
GPU utilization for systems with no visual interface, but have a GPU as a part of the
CPU
Disk or network-storage utilization
Abnormal changes in system time on a particular host
While monitoring systems for capturing anomalies are readily available, the context may be
specific to the application or infrastructure used by the organization. Consult with the
V1.1 Page 32 of 61
business providing the monitoring system to determine how to capture and interpret metrics
in a way that is most effective for the specific implementation.
Separate tiers may have differentials in anomalies indicating an attack or compromise.

Evaluate what those indicators are per each tier.
recommendation
Amazon EC2 Monitoring Documentation

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring_ec2.html
Google Cloud Monitoring
https://cloud.google.com/monitoring/
Microsoft Azure Monitoring
https://azure.microsoft.com/en-us/documentation/articles/best-practices-
monitoring/
DigitalOcean Monitoring Tutorials (General)
https://www.digitalocean.com/community/tags/monitoring?type=tutorials
5.7.1 Risk
Systems monitoring technology is a key attribute of the IoT security model. Without
monitoring, there is no way to determine if a vulnerability has been found in critical service
components. Monitoring allows administrators to quickly diagnose pain points in service and
infrastructure, and can assist in differentiating between security incidents and software bugs.
5.8 Define an Incident Response Model

It isnt enough to detect a potential compromise or an on-going attack. The organization
must be able to react to, and combat, the attack. If a system is compromised, cleansing or
shutting off that system is not enough. The organization must, instead, be able to diagnose
the source of the compromise, patch the system, and deploy the patch on all existing
infrastructure.
This may be difficult if a container-based environment is used where cloned applications are
running with a vulnerable configuration. The application system must be able to detect a
reboot or update event, where the application connection is handed off eloquently to
another system in the Cloud, or the user is forcibly logged out, to permit the update to occur.
No matter what the execution model is, however, the engineering team must be able to
capture metrics in a way that allows for forensic analysis. These policies and procedures
must be set in stone and approved by the legal (and possibly the insurance team) to validate
whether the information is contained in a way that is suitable for Law Enforcement Officers
(LEO). Compliance will assist in ensuring the business is not only complying with local and
federal law, but is providing samples of a compromise that can be used in court.
V1.1 Page 33 of 61
Once the samples are captured, each aspect of the overall system should be assessed for
logs, metrics, and other data that can corroborate to the event in question. This data should
all be captured and stored in a secure system for legal review.
recommendation:
CERT Recommendations for Creating a CSIRT

http://www.cert.org/incident-management/products-services/creating-a-csirt.cfm
5.8.1 Risk
Organizations that lack an incident response model will take far more time to organize their
resources, identify compromised systems, quarantine those systems, and review the
systems for information. This also significantly slows the efforts that should be made to patch
and restore a given system. This unpreparedness grants adversaries a large window of
opportunity to leverage one compromise into lateral or vertical movement within a given
environment. This may result in a significantly larger compromise due to the increased
response time. Organizations should be prepared to respond to an incident almost
immediately to reduce the amount of time an adversary has to control critical portions of the
service.
5.9 Define a Recovery Model

Regardless of whether a user or application is affected due to a security compromise or a
hardware fault, a recovery must occur. A procedure should be put in place for recovery of
information and capability within application tier. The procedure must be tailored to the
context of each application and tier.
For example, if an application has gathered information from an Endpoint regarding the
output of a particular action, and there is a storage fault that disallows the application from
solidifying the output of that data in persistent storage, the application can:
Attempt storage again until it succeeds (May be endless)

Attempt storage for a limited number of attempts until success or failure thresholds
Fail immediately, potentially losing the metrics
Ask the Endpoint again for the same data (May never be available)
The method that is most suitable for the application and business requirement must be
chosen. This, again, will depend on the context of the application, and may not be easy to
model outside of a given system.
Engage both the engineering and business leadership to determine how a failed or
compromised application should recover, especially in the context of user activity.
For systems that have been provably compromised by an adversary, there must be a model
in place for validating that the application or system has been sufficiently patched prior to
recovery. Without this policy and procedure set defined, a vulnerable system may simply be
redeployed into the Service Ecosystem, facilitating further compromises.
V1.1 Page 34 of 61
5.9.1 Risk
Recovery models ensure that information, applications, and configurations are restored
correctly. Without a restoration model, the team may unintentionally redeploy vulnerable
subsystems to servers or infrastructure. Also, tainted data that could have been manipulated
by an adversary in a database or storage environment could be replicated across multiple
systems, unintentionally propagating malware or simply altered data. Recovery processes
reduce the ability for adversaries to abuse weaknesses in the recovery of an incident, which
adds to an already expensive event.
5.10 Define a Sunsetting Model

Every system that is deployed by an organization, and every tier used, has a lifetime. Even if
the same product or service is deployed by the organization for decades, the technologies
used to drive that product or service will change. Thus, there must not only be a plan for
designing and implementing the product or service, there must be a plan to sunset that
product or service.
This process helps guarantee that all technologies are revoked and decommissioned in such
a way that an adversary cannot take on the identity of, or use the facilities of, the given
technology. For example, a simple case is a domain for a particular product after a
businesss acquisition by a parent company. If the product is renamed, and the domain is
migrated to the parent companys domain, an adversary may be able to take ownership of
the now defunct domain. If the adversary can issue cryptographic certificates for that domain
and still interact with deployed technology under that old domain, there will be a significant
gap in security caused by a lack of procedure in the sunsetting of that product or service.
Each technology used in the architecture, implementation, and management of a given

product or service must, then, be catalogued and evaluated for its usability. Once that
technology is no longer usable, it can be sunsetted according to its model. This allows
engineers and business leadership to migrate the technology over to a more suitable set of
innovations without gaps in the underlying platforms. It also ensures that a product that will
no longer be offered to partners and users will end its lifetime without the potential for
exploitation by adversaries after the business closes down.
5.10.1 Risk
A lack of a sunset process can result in both Endpoints and services being compromised by
competitors or adversaries. This is possible legally because if an organization releases
access to certain objects, such as domain names, phone numbers, and other renewable
services, an adversary or competitor has the right to acquire those objects, even if it seems
unethical. This may open devices or services up to unscrupulous abuse or even malicious
behaviour.
5.11 Define a Set of Security Classifications

To properly manage interactions with Partner organizations effectively, security
classifications must be defined. This will set the tone for not only the internal organizational
V1.1 Page 35 of 61
policy on data security, but will help define the level of security Partner organizations apply
to the businesss data, their own data, and customers data.
While this process should be investigated and tailored to the organization, most data security
classification policies should start out with the following classes:
Public - Any entity granted access

Classified - User must authorize release
Secret - User-specific data
Top Secret - Organization-specific data, never to be released
After defining the basic classes, the organization must evaluate how each security class
should be attributed to a data class. In other words, evaluate how the classification should
be used in practice, not just in theory. Determine what policies and procedures should be put
in place from a business and engineering perspective.
This will allow the organization to not only build technical policy, but enact business policy
that supports the technical requirements. This makes it easier for the engineering team to
hand off these requirements onto partners and internal organizations that would seek to
break the policy, either intentionally or unintentionally.
Once the security classifications have been standardized, it is important to evaluate how the
security classification model can be affected by privacy requirements of the business and its
users. The organization must take the time to apply a privacy model to the security
classifications, to give meaning to users data, and help protect their privacy in the event that
a Partner wants access to specific resources that could put users at risk of exposure. By
contextualizing privacy in the context of security classifications, Partners will need to seek
approval by the business leadership and users, when Partners want to acquire certain types
of privacy-centric data. The users must have the option to guard their privacy-centric data,
and must be able to limit the exposure of their data to third parties.
5.11.1 Risk
Classifying models for security is imperative toward architecting solutions that use security in
an effective manner. In order to protect information, that information must be quantified so
that appropriate controls can be formulated based on corresponding policies and
procedures. Without these models, engineers tend to implement security either too intensely,
or not at all, depending on their perception of the risks involved. The entire team, including
both engineers and business leaders, should identify what data means to the business and
how it should be secured within an appropriate range of cost-effective controls.
5.12 Define Classifications for Sets of Data Types

After defining security classifications, the organization should define types of data to be used
by the overall IoT product or service. This will enable the organization to clearly define what
types of information are acquired, generated, and disseminated to peers in the IoT system,
and how the organization should treat these types of data. This data will provide context and
value to the overall components used throughout the IoT environment.
V1.1 Page 36 of 61
While this document will not attempt to model all variations of data that may be relevant to a
specific organization, certain types may be as follows:
Users
Actions
Images
Editable documents
Personally-Identifiable Information
Protected Health Information
A piece of information may be attributed one or more types. But, the data itself should be
attributed only one security class. While the type identifies what the data represents and how
it should be processed, the security class will represent how, where, and when the
information can be used, and to whom it may be shared.
Defining the various types of data and attributing classifications to them is a long-winded
process. Doing so sets an organizational standard for the business and allows the
engineering team to execute technical controls around the data and its classifications. This
greatly assists the engineering and business leadership teams later when negotiating with
Partners over how data can be shared and processed.
5.12.1 Risk
As with security classifications, controls cannot be implemented around data without
quantifying what that data is, and what relationship that data has to the business. These
classes define how the information should be used within the system, and what protections
must be applied to the data in order to maintain an appropriate security posture. Without
these classes, engineers have a tendency to apply too stringent or too weak of security
measures. Security measures should be agreed upon by the engineering team and business
leadership, to balance the controls with the importance of the data to the business.
V1.1 Page 37 of 61
6 High-Priority Recommendations
High priority recommendations represent the set of recommendations that should be
implemented, but only if the endpoint architecture requires it. For example, not all endpoint
architectures require tamper resistant product casing. These recommendations should be
evaluated to determine if the business case deems them a requirement.
6.1 Define a Clear Authorization Model

While the privacy model deals with the way users information is offered to Partners, the
authorization model defines how the business or Partners will act on behalf of a user. This,
for instance, would come in handy for a home automation system where a Partners metrics
could optimize the use of heating or cooling in a given home. The authorization model would
grant the Partner the ability to change heating or cooling controls for that users home when
certain metrics were detected by the Partner.
To accomplish this, have a similar GUI that describes granular authorization capabilities, and
how they will be distributed to Partners. Allow the user to grant access, or revoke access, to
certain capabilities on demand. Ensure that revoked capabilities take action immediately, to
diminish the potential for abuse.
The system must be heavily monitored to ensure that Partners do not take actions that they
are not allowed to take. Granular control of the authorization model should allow users to
configure when Partners have access to certain capabilities, and how often. Attributes like
this will improve whether a user can take control of their system from a potentially abusive,
or compromised (hacked), Partner.
6.1.1 Risk
Without an Authorization Model, third parties will not have restricted access to a users
capabilities. This may allow a rogue or compromised third party to acquire full access to a
users technology or data. By creating an authorization model, access is restricted to only
the attributes that a user will allow. This enables the user to have greater control over what
capabilities and data are made available to third parties, and reduces the risk of the IoT
Service Provider by mitigating the potential for widespread compromise.
6.2 Manage the Cryptographic Architecture

All technology deployed in an IoT environment must use cryptography, regardless of
whether the technology is a rudimentary low-power endpoint, or a robust Cloud service. To
properly implement security in an IoT product or service, the cryptography used must be well
architected, managed, and adjusted to meet changing specifications over time.
The engineering team must identify whether:
Their cryptographic algorithms have been deprecated

They are using cryptographic keys with adequate bit-lengths
Hashing algorithms are subject to collision attacks
A strong random number generator is used
Messages are sufficiently padded with random data
V1.1 Page 38 of 61
Cryptographic protocols, such as TLS, are up-to-date with best practices

Privacy-centric concepts, such as forward secrecy, are used
Plaintext passwords or pin numbers are passed over the network
A custom cryptographic algorithm was used
Each of these points, and more, are important to maintain a high quality cryptographic
architecture within the IoT product or service. Success in deploying a cryptographic solution
is tightly bound to the engineering teams ability to leverage the most resilient cryptography
solutions for deploying patches to technologies that use less resilient solutions.
For example, the RC4 algorithm was recently discovered to have significant security flaws. If
a patch can be securely distributed to clients configured to use RC4, that replaces RC4 with
AES-256, then RC4 becomes less of a concern. If mutual authentication is performed using
a more resilient technology, such as Ephemeral Diffie Hellman key exchange and
asymmetric keys, or a UICC security token, the patch can be verified without using the
vulnerable cryptographic algorithm.
Passwords and pins used by a user or endpoint should never be passed over the network in
plaintext, even if the communications channel is secured through encryption. Instead, the
cryptographic hash of the password or pin should be used, to ensure that any
misconfiguration in the cryptographic tunnel does not expose the password, itself. The hash
should be generated by the password and at least one unique one-time token. While it is
common for this token to be taken from the network session, it is more secure to take the
value from a rolling code stored on both the endpoint and the service infrastructure. This
way, an attacker with a position of privilege on the network cannot seed the hash with
beneficial values, which may result in a forced-signing attack.
Custom cryptographic algorithms (algorithms designed in-house) should never be used.

Always use recommended algorithms developed by cryptographers, and recommended by
oversight organizations that specialized in cryptographic security. Always avoid the use of
poorly designed algorithms, deprecated algorithms, or compression, binary-to-text, or other
algorithms commonly mistaken for cryptographic algorithms, such as LZO, base64, ROT13
and XOR.
Please review the following guides and references for more information on this topic:
ISO 18033-1:2015 Encryption Algorithms

ISO 18033-2:2015 Asymmetric Ciphers
ISO 18033-3:2015 Block Ciphers
www.owasp.org/index.php/Guide_to_Cryptography
csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
csrc.nist.gov/groups/ST/toolkit/key_management.html
6.2.1 Risk
Properly deploying a solution with a cryptographic architecture ensures that the algorithms,
protocols, and secrets utilized all fall within the current recommendations. In addition, the
recommendations change over time. Without a cryptographic architecture it will be more
difficult to identify all of the technologies that have deprecated, which creates an opportunity
for gaps in security.
V1.1 Page 39 of 61
6.3 Define a Communications Model

Each system in the Service Ecosystem must be capable of mutual authentication. No
computing platforms within this ecosystem should be accessible to anonymous public users.
Each Endpoint, Partner, or User will communicate with the Service Ecosystem through
technologies that require mutual authentication. Since the services that make up the user
interface are typically deployed and managed in a separate environment, the publicly
accessible interface must be confined to that space. The Service Ecosystem, however,
comprises the set of all system used to deploy service to all authenticated resources.
This includes Endpoints that have not yet been provisioned by the system, as the hardware
fabrication and personalization process should configure the hardware adequately enough
that it may be authenticated as a business-deployed resource.
Therefore, the communication model must provide:
Mutual authentication
Confidentiality
Integrity
To accomplish this effectively, the communications model must also provide:
A centralized root of trust or, alternatively, a decentralized root of trust

Identity provisioning and revocation
Perfect Forward Secrecy
A root of trust must be used to ensure that each entity in the communications model is
authorized by the same organization as the peer. This helps to ensure that all entities have
been provisioned and authorized by one central organization. The technology used to
ensure this root of trust may be centralized (similar to TLS certificates) or decentralized
(similar to IoT models based on Bitcoin blockchain, for example IBM/Samsungs ADEPT
project, Tilepay, and others). Regardless, one central business must be the owner of the
model, and guard the provisioning system.
Provisioning and revocation must be a part of the communications model, to help guarantee
that any compromised secret or identity can be removed from the system with minimal effort.
Technologies such as Online Certificate Security Protocol (OCSP) help with this process.
The communications protocol must employ a technology that mitigates the potential for
compromising communications from the past. This is done by creating ephemeral
asymmetric cryptographic keys that are used to exchange a communications secret. If a
certificate is compromised, the ephemeral secret will not be. This ensures that storing
encrypted messages for a long period of time will not later result in an adversary decrypting
them if the certificate private secret is ever compromised or exposed.
The challenge with communications security is in the implementation and longevity of the
technology. Encryption algorithms can be selected that are held in a high degree of
confidence by authoritative entities, diminishing the potential for failure.
V1.1 Page 40 of 61
Libraries and algorithm implementations designed or approved by engineering authorities

must be used. Custom implementations of algorithms must not be used. This diminishes not
only the engineering teams work, but the potential for an algorithm to be cryptographically
weakened by a poorly designed or incorrectly implemented system.
recommendation:
CafeSoft Apache Mutual Authentication How-To Guide:

http://www.cafesoft.com/products/cams/ps/docs32/admin/ConfiguringApache2For
SSLTLSMutualAuthentication.html
6.3.1 Risk
Communications security is the cornerstone of IoT. Without communications security, there
is no guarantee that embedded devices are communicating with the correct back-end
services. This is imperative for critical services that guide, configure, and send commands to
devices such as telematics, medical devices, and industrial control systems. Without
communications security, there are no guarantees that commands are being sent to the
correct endpoint. Enforce communications security to ensure that messages are being sent
to and received from the intended peer.
6.4 Use Network Authentication Services

Network Operators, when used as partners, allow users to be authenticated using tokens
specific to the network operator. While these tokens, present in the Network Operators
UICC, authenticate a user to the network layer, they dont necessarily authenticate the user
at the application layer. The use of the following technologies may facilitate network
authentication:
Generic Bootstrap Architecture (3GPP TS 33.220)

M2M SM (ETSI TS 102 921)
Evaluate whether the authentication technology will create meaning at the application layer,
for authentication purposes. If the token can be used as a security store, determine whether
the device can be used as an authentication layer for the physical Endpoint to build a TCB
using the token.
While many network operators enforce network-based authentication, granting access to this
API to authenticate either users or Endpoints is a fairly new technology. Evaluate whether
the Network Operator you are working with creates a meaningful experience in this space. If
so, consider using this technology as more than a network layer authentication token, as it
may be easier to utilize one security store technology, instead of multiple technologies.
6.4.1 Risk
When network authentication services incorporate trust anchors such as the UICC, not
utilizing these services to secure the application layer will limit the ability for the application
to reliably authenticate users and will increase the expense of the underlying Endpoint
V1.1 Page 41 of 61
platform. This increases the cost of deployment and also decreases the information available
to the organization from the Network Operator.
6.5 Provision Servers Where Possible

Server provisioning involves defining, configuring, personalizing, and deploying a server in a
production environment. The provisioning process, from a service perspective, ensures that
a server is security hardened and ready for deployment in an environment that may be
potentially hostile.
Regardless of whether the server is deployed in a Cloud infrastructure, a dedicated hosting

provider, or in a companys personal rack space, a server will be vulnerable to both insider
and external threats. The server must then be hardened from attack before it is ever
deployed in the service infrastructure.
To accomplish this, identify the services that should be accessible to the surrounding
environment. Define whether the environment the server will live in will be public or private,
and what that means in the context of server security. Determine whether each service
running on the server should be accessible to the public, or whether only authenticated
clients must connect to the service.
Evaluate the lifecycle of the operating system that will run on the server. Determine how to
properly manage software updates to ensure that security patches will be quickly deployed
and committed to servers working in production. Evaluate a roll-back model in the event that
updates fail or cause unexpected issues with production services, as some library or
application updates may result in unintended side effects.
Finally, evaluate the sunsetting model of the provisioned server to determine the most
secure way to remove assets from the system. This includes system logs that may be
required for assessing anomalous service or client behaviour.
This recommendation implies that a Patch Management process should be implemented by

the organization to identify vulnerable services, deploy patches, and monitor the success of
implementing those patches.
Please review the following material on Patch Management:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf
6.5.1 Risk
Server provisioning is an imperative part of the overall security of an IoT environment.
Without it, the organizations control over the server architecture will be substantially
weakened. This may result in gaps in security due to a lack of architecture specification.
Without a specification, the organization cannot review whether the deployed technologies
adhere to modern best practices. In addition, improving these technologies will require
investigation of each deployed system to evaluate the deltas between deployed assets. This
is inefficient and a high concern in the event that a critical security update needs to be
deployed. If there is no consistency and no architecture to define the services, there will be
V1.1 Page 42 of 61
no way to easily track which systems require immediate attention without manually checking
each one.
6.6 Define an Update Model

Updating an execution environment, application image, or TCB is a challenging process.
Consider the following example model that simplifies the overall process:
For each layer of the execution platform, define a network resource such as a unique
URL for the new application image
Generate a signing key for each specific layer
For all new, authorized versions of each layer, generate an image of that layer
Include metadata describing the image (version, timestamp, identity, etc.) in the layer
image
Sign the layer image with the signing key
Make the image, the signature, and the public key available, possibly via the unique
network resource, or through a update service
When a new system is deployed it should:
For each layer:

Retrieve the version(s) to be deployed
Cryptographically verify the image
Deploy the image layer on the system
No private secrets should be stored in any application layer. Instead, secrets must be
provisioned dynamically as each system is deployed, to personalize each system. These
identities should be revoked as the system is decommissioned, no matter what the lifetime
length of that system is.
This recommendation implies that a patch management process should be used to maintain
services and technologies within the infrastructure.
Please review the following documentation for more information:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf
6.6.1 Risk
Without a well-defined update model, services and applications risk compromise through
abuse of the update procedure. Adversaries may be able to inject custom applications into
the update process and deploy their own software onto Cloud systems and other servers. If
the communications security infrastructure is not secured, this can easily be performed
simply by manipulating network services such as Domain Name Service (DNS). More
advanced attacks against routing, such as Border Gateway Protocol (BGP) attacks, have
been implemented many times in the past to compromise insecure services.
6.7 Define a Breach Policy for Exposed Data

Defining policies and procedures for the classification of data is not enough. There must also
be a model for detecting whether the data has been exposed by a Partner. The organization
must have a plan in place to evaluate whether a Partner was involved in business practices
V1.1 Page 43 of 61
that breach the technological controls or policies set in place to guard users data and
privacy.
To accomplish this, the engineering team must define monitoring and logging technologies
that apply to security classifications and not simply user data. This will allow an auditing trail
to apply not only to information, but to the classification of that information. This will help the
organization defend itself in the event that user information is exposed. The organization will
be able to show that its security classifications, and the technical controls put in place to
manage those classes, managed, stored, and disseminated the data according to policy.
It is beneficial that the organization use the monitoring and logging technology to prove when
a Partner has broken the rules of the security classifications. The leadership should, at that
point, decide whether or not the Partner should be subject to fines, dismissal, or another
consequence.
6.7.1 Risk
Without a breach policy, there are few legal guards to protect the organization from liability of
data that has been exposed by a third party. If the business is the source for the exposed
data, the third party may have lost the data, but the business is liable for the data it hands off
to its partners.
Breach policies ensure that partners must uphold a level of security adequate for the data
that they are being provided. Any breach of that security helps to removes the liability from
the IoT Service Provider as long as the IoT Service Provider follows its own security
requirements. Then, it is up to the partner to adhere to the policy.
These policies should be reviewed by legal and insurance teams to ensure that the models
do, in fact, reduce the liability of the organization by adhering to stringent security policies
and procedures. Some businesses, due to the nature of the products or services they offer,
may not be exempt due to regulations, legal statutes, or other issues.
6.8 Force Authentication Through the Service Ecosystem

A user interface should never authenticate a user directly. The system must always be able
to authenticate the user by using the centrally available service. The only exception to this
rule is if an application running on a mobile device is guarded by a local passcode. This
passcode may be used to access the local application. However, access to remote services
and resources should be verified by a separate authentication token.
Although, for usability, the engineering team may choose to collapse these two
authentication schemes into one if the user is provided with sufficient information that
describes to them the risks in utilizing this method of authentication. Such a method would
enable an authenticated users local application password to decrypt a local database
containing an authentication token that works on the remote service. This multi-step
authentication model may be sufficient for most users.
Regardless, the central Authentication Service must first authenticate the user to the local
application, then enforce policies and procedures that mandate how that authentication
token can be used, and for what period of time. Metrics should also be gathered to
determine if the user has migrated to an alternative computing platform, but is using the
V1.1 Page 44 of 61
same token. Or, if the user has migrated to another location in a short period of time, but is
using the same token. Depending on the type and speed of movement, these metrics may
indicate a potential compromise of the token. At which point, the token should be invalidated,
and the user should be forced to log back in, potentially by using multi-factor authentication,
where applicable.
6.8.1 Risk
Due to the abuses possible in Endpoint systems, regardless of how secure the architecture
can be, authenticating a user without confirmation from a back-end system is always
unreliable. This presumes that the user has not updated their credentials, or can fragment
credentials across multiple types of devices. This is inefficient and may open up a gap where
a compromised device is using an older version of the users credentials.
6.9 Implement Input Validation

All data acquired from an endpoint, user, or purported user, must be analysed for anomalies.
The easiest route of attack for an adversary is always abusing web application input in the
services that make up the user interface. This is because this technology must render
information dynamically, based on the variations in locality, encodings, and other parameters
that change from user to user. Skilled users can manipulate certain attributes of encodings
to cause unexpected side effects beneficial to an adversary at different layers of the
processing subsystems.
For example, a fascinating attack includes the encoding of a null byte into messages that are
processed as strings by higher level languages. Some high level languages accept null
bytes as part of a binary string, rather than seeing it as a delimiter. When this binary string is
passed down to lower level libraries, the embedded null byte is interpreted as a string
delimiter, truncating the string to mean something entirely different than what the application
interpreted the string as. In the past, this has been a clever way to access file system
resources that would otherwise be unavailable to a particular user.
While there is an infinite number of variations for malicious input to take form, engineers do
not need to test for every possible case. Instead, the process is fairly simple:
Identify how the data shall be used internally

Enforce a policy around what kinds of encodings and characters adhere to the
internal use model
Design an API that analyses the data according to this policy
Raise an exception when data has been identified that breaks the model
Log the event internally with metadata regarding the session to help detect
adversarial behaviour
All data stored within the system should first be processed and composed into a static
model. An effective technique for this is simply encoding all data with the base64 algorithm,
then placing it in a database. This ensures that the data can in no way manipulate the
database.
V1.1 Page 45 of 61
6.9.1 Risk
Systems that do not employ input validation are subject to an array of possible attacks
including issues referenced in the OWASP Top Ten such as SQL Injection (SQLi), and even
remote code execution attacks. Because the range of potential abuses is so wide, the risk
cannot be fully quantified here. Input validation is a critical attribute of any secure
application, whether it is a cloud service or an application running on an Endpoint.
6.10 Implement Output Filtering

Output filtering is the complement to input validation. This process not only secures the
presentation layer from adversarial manipulation, but also disallows the system from rending
information to a user that should be deemed privileged.
In the first case, all data to be rendered by the presentation layer must be assessed prior to
it leaving the service layer. This will ensure that data encoded into the presentation layer, for
example, in JSON messages or encoded JavaScript, does not contain formatting that could
break or invalidate the presentation of the data. This means that any characters stored in the
system that, if rendered, could break the presentation model must either be filtered out or
encoded in such a way that they do not alter the presentation in unexpected ways.
A methodology for remediating this issue is either filtering restricted characters out, enforcing
an encoding on all characters so that the presentation of these characters does not alter the
GUI (the characters arent interpreted by a rendering engine as control codes), or simply not
displaying the message. While any of these methods work, some are more appropriate in
certain applications. Reviewing the message forum example, it would be just as bad if an
adversary were able to place scripts that other users can copy and execute without knowing
what they are doing. Therefore, instead of just rendering the information in a way that
doesnt inject HTML or other scripts into the presentation layer, the information should be
scrubbed so that other users are not affected.
In the case where data should not be presented back to the user, this does not relate to data
stored and rendered by an adversary. Rather, this issue relates to the manifestation of data
that isnt suitable for public consumption, and should be reserved for administrators and
engineers. For example, if an internal error is generated in processing information, that error
should not be rendered, with its full debug data, to the user. This may allow a user to identify
and instrument a bug for the purposes of exploiting weaknesses in the application. This
information should be internally logged, and a generic error should be raised to the user that
does not provide enough context for the user to abuse the bug. Even if the user can
reproduce the bug, the user should not be able to evaluate a differential in output from the
application that indicate improvements in the exploit methodology.
6.10.1 Risk
Output validation is a critical attribute of IoT security. Systems that do not perform output
validation risk exposure of critical user data, privacy related data, diagnostic data, verbose
error messages, and more. These messages may be used to expose user information or can
be used to create a reliable exploit against a networked service.
V1.1 Page 46 of 61
6.11 Enforce Strong Password Policy

It is imperative that all authentication systems enforce strong passwords where passwords
are required for user authentication. Password complexity has been a constant battle
between information security researchers, engineers, and business leadership. Business
leaders often want users to be able to remember their passwords easily. Engineers need to
reduce the complexity of interfaces, especially for designers of the presentation layer.
Information security researchers often overestimate the skill of an attacker and press
unnecessary complexity onto a given technology.
The answer, however, is somewhere in between all the requirements of each group.
Passwords should be forcibly long, but should not be complex. While eight character
passwords used to be the norm, and some systems even allow 6 characters even at the time
this document is being written, the password length should be taken from the latest best
practice standard, but will likely far exceed even 8 characters. By enforcing a longer
password length, the complexity requirement is reduced. Instead of enforcing bizarre
assortments of various character sets, the user can simply remember a sentence. Because
they can choose to utilize white spaces, capitalization, numbers, and punctuation, the
complexity is automatically skyrocketed for any attacker applying brute-forcing.
Lets not forget, there are typically four ways an attacker will compromise a password:
By stealing the password database and cracking individual passwords

By brute-forcing the application authentication service
By installing malware
By using hard-coded or default passwords
Forcing long passwords helps diminish the first risk. But, security at the Service Ecosystem
layer is far more beneficial. The attacker shouldnt be able to retrieve the password database
in the first place, which brings us to the second point.
Brute-forcing application passwords is then the most effective way an attacker can abuse
passwords. This potential is significantly diminished by a properly designed authentication
service. If one bad password has been guessed, the system should automatically start
increasing the amount of delay required between guesses. Then, a threshold must be
defined that limits the total number of attempts. If the attacker reaches this threshold, the
account should be locked, and two-factor authentication, or another model, should be used
for the user to unlock and verify their account. This type of security substantially reduces the
benefit of a network based attack, which brings us to the final point.
Malware on the client system is something that must be dealt with by the computing
platform, or by the user installing the appropriate combative technology. This is typically not
something that can be secured by the application, itself. Since there is little to nothing the
application can do to combat this risk, beyond enforcing 2FA, the application engineer will
have satisfactorily reduced the threat surface of password attacks against the authentication
system if this is an adversarys only viable course of action.
It must be noted, however, that the reward for implementing this recommendation is not
high. This is because no matter what technologies are used to reduce the potential for
attacking password authentication, passwords are, essentially, an intangible resource. They
are not physical tokens that can only be captured by a single individual. Rather, it is an
V1.1 Page 47 of 61
abstract object that can be copied infinitely across computer systems and through visual
observation. Therefore, they are a significantly weak source of authentication that does not,
in any way, adequately indicate a particular user. Therefore, passwords, themselves, are a
weakness, and any technology using passwords is subject to the risks that passwords
inherently imply.
Passwords should never be hard-coded in the system. For endpoints, unique cryptographic
keys should be generated. Refer to the Endpoint document for more information on endpoint
provisioning. For services and user interfaces, the password should be defined by the user
when they register. The password, at that time, must adhere to strong password security
requirements. Never allow a user to utilize a default, weak, or poorly designed password.
Ensure that the user always has the ability to change their password at any time. Enforce
strong authentication requirements and communications security in order for the user to
change their password. Where possible, enable two-factor authentication (2FA) to verify the
identity of the user prior to allowing a password change. Always force a user to re-enter their
original password when they submit a new password to the system. This ensures that
another user hasnt usurped an open web application by taking advantage of an unlocked
laptop, or stolen a web application session token.
6.11.1 Risk
Systems that dont enforce adequate password controls risk the ability for adversaries to
easily guess passwords from users of the system.
V1.1 Page 48 of 61
6.12 Define Application Layer Authentication and Authorization

While the Organizational Root of Trust and its services will define authentication
technologies that secure the network communication layer, the user, administration, and
partner authorization technologies must be configured separately. While these entities
communications channels are secured with the Organizational Root of Trust, their actions
and identities must be authenticated using a separate system.
Generally, this application layer authentication will be facilitated by the same service.
However, information will be gathered from a separate resource. For example, it is best to
place user and administrative authentication data in separate databases. This ensures that if
there is a way to manipulate the database through the application layer (for example, using a
SQL injection), attackers may only move laterally through the user database. They may not
move vertically, elevating their privileges to administrator, without compromising the
database, itself. This is a significant improvement in organizational security.
If possible, define separate storage systems for:
Endpoint identities
Users
Administrator credentials
Partners
This will create a logical separation of duties for applications and infrastructure, but within
the same authentication API managed by the Organizational Root of Trust service.
recommendation:
OAuth 2.0 [8]

OpenID Foundation [9]
GSMA Mobile Connect [11]
6.12.1 Risk
Without a methodology for enforcing application layer authentication and authorization, there
is no way for the system to confirm the actions purported to be from a user are actually
authorized by that user. Implementing this recommendation ensures that each action is
traceable to an authenticated user and an authorization. These metrics can be stored and
later reviewed in the event that a compromise is suspected. Without these steps, there will
be no safeguards that minimize the risk of abuse.
6.13 Default-Open or Fail-Open Firewall Rules and System Hardening

In some service infrastructure environments, ingress and egress protection mechanisms are
not configured by default. This means that engineers must employ firewall or network traffic
rulesets themselves. These rules must be set in infrastructure before any service is deployed
to the public.
V1.1 Page 49 of 61
Yet, there are times when these technologies may not be sufficient in protecting service
infrastructure. Sometimes, firewalls and other network traffic protection systems fail. When
these systems fail, they often fail open. The reason for this is that if the system fails, traffic
must still be able to work, as traffic for other computing environments will be routed through
the infrastructure along with the IoT Service Providers traffic. Thus, traffic cannot suddenly
come to a stand-still. As a result, the system often fails open to allow as many services as
possible to continue working.
The engineering team should employ operating system hardening to ensure that the effects
of failed infrastructure do not result in a catastrophic security event. Instead, it simply means
that more connections can be made to existing service infrastructure.
For example, hidden services should not be placed behind technology such as firewalls.
Instead, Virtual Private Networks (VPNs) or other high-security protections can be used to
secure the services from adversaries.
Note that software firewalls carry an additional risk, in that they can be manipulated by a
savvy attacker. If a software firewall is used, any server infrastructure that is improperly
hardened may be manipulated by an attacker. In other words, if a public service running on a
server carries unnecessary privileges (such as super-user privileges) and is compromised,
the attacker will likely be capable of disabling the software firewall. Thus, the engineering
team must evaluate whether a software firewall is too high of a risk for the chosen
architecture.
6.13.1 Risk
Without employing strategies to compensate for failure in the network traffic security
systems, the environment will be subject to unnecessary attacks that could be easily
prevented with standard service hardening strategies.
6.14 Evaluate the Communications Privacy Model

Communications privacy is a slightly different topic than application privacy (described
above) or communications information security. While privacy is largely evaluated from the
ability for third parties to effectively read or intercept data, confidentiality and integrity do not
represent the full scope of communications privacy.
Other issues that affect communications privacy include:
Cryptographic uniqueness of each message

Transmission patterns
Plaintext metadata
Hardware addresses or attributable serial numbers
While each message should be confidential and have verifiable integrity, they must also be
cryptographically unique. If certain messages are sent in response to events that are
predictable by an adversary, any responses that arent cryptographically unique may be
replayed by the attacker. Each message should be unique to disallow the attackers ability to
capture and replay messages that are beneficial.
Patterns in transmission can allow an adversary to identify a particular user, or equate

behaviour with a certain attributable action. For example, technology that emits a message
V1.1 Page 50 of 61
when a user enters a certain physical zone may be fingerprinted by sniffers that are
capable of receiving these messages as they are transmitted through the air. While it may
not be intuitive, this is a potential liability if an adversary can identify who is in a physical
location and where they are in that location. Network patterns should be assessed to
determine if there is a simple way that adversaries can turn transmission patterns into
actionable data.
Metadata has long been used by intelligence services to evaluate the context of messaging
systems without requiring a warrant or other legal access to encrypted data. Often, the
metadata is enough information for an organization to create actionable intelligence.
However, now hobbyists, criminal organizations, and curious users are able to use metadata
for tracking and other potentially nefarious purposes. As a result, it is more important than
ever to diminish the amount of metadata available to third parties. Where possible, limit the
amount of metadata to only enough information required for a communication peer to
evaluate whether the message is intended for them.
Along that line of thought, the hardware address of the communication module, and any
unique serial numbers, should be protected or randomized, if possible. For example, Apple
changed the iOS model for probing Wi-Fi access points. Instead of using the static hardware
address, they changed their technology to use a randomized hardware address, which
diminishes the potential for someone to track a users location based on Wi-Fi active scans.
IoT technology will function similarly, but will have a larger set of communications
technologies affected by this issue. Some technologies will not be capable of random
hardware address generation, such as cellular. But others, such as 802.15.4, Wi-Fi, and
Bluetooth, may be capable of this depending on the firmwares functionality.
6.14.1 Risk
While it should go without saying that communications security is a requirement, it is
sometimes confusing as to why it is a requirement. Communications security doesnt just
ensure that an adversary cant read data. It also ensures:
An Endpoint cannot be impersonated

A critical service cannot be impersonated
Abused messages can be detected
Changes to software or security configurations can be performed safely
Without communications security, there are no guarantees as to the quality, reliability, or
privacy of an IoT product or service.
V1.1 Page 51 of 61
7 Medium-Priority Recommendations
The medium-priority set of recommendations encompasses the set of recommendations that
are relevant depending on the design choices of the endpoint technology. For example,
enforcing operating system level security enhancements is only valid if there is an operating
system running on the endpoint. If the endpoint is composed of a monolithic kernel
application, or an embedded Real-Time Operating System (RTOS) with a single embedded
application, the recommendation may not apply. Where recommendations do apply to the
endpoint design, they should be implemented.
7.1 Define an Application Execution Environment

Several points must be made about application execution environments:
The programming language used may have a direct relationship to security:

Languages like PHP and Ruby may present security concerns
Languages like GoLang and Erlang may decrease risk
Third party libraries must be monitored, managed, and audited for risk:
Some libraries arent well maintained
Some libraries have never been audited for security flaws
Some libraries require out-of-date dependencies that have known security flaws
Always run an application as a non-privileged user:
If the application requires a privileged resource, use a wrapper to provision that
resource before dropping privileges and executing the full application
Use a well-defined TCB and Bootstrap model:
Applications that have well defined environments are more reliable and more
secure
recommendation:
OWASP [5]
7.1.1 Risk
Applications that are deployed with a secure architecture can be subject to compromises
that cannot easily be traced back to a specific source. Tools and techniques for
compromising services and applications have become advanced in the past decade. Some
open source technologies, such as Metasploit, allow the development and integration of
custom exploits into an attack platform that can provide technologies to increase the stealth
of an attack.
A secure Application Execution Environment can combat this risk by securing the way
applications are ran, interact with each other, and the types of technologies that are used
during runtime. These attributes can not only lessen the likelihood of a compromise
occurring, they can add traceability and critical logging capabilities to track and diagnose the
abused vulnerability.
V1.1 Page 52 of 61
7.2 Use Partner-Enhanced Monitoring Services

If the Partner being utilized is a Mobile Network Operator, identify whether they are able to
offer monitoring services. Some network operators are capable of analysing the behaviour of
endpoints communicating through their network. Operators with this type of capability have
experience evaluating what metrics equate to anomalous and adversarial behaviour.
This will allow the IoT business to more quickly identify whether a particular user or Endpoint
is either a threat, or has been compromised by an adversary. As a result, businesses may
react more effectively to pre-empt attacks against other areas of the businesss
infrastructure.
The complexity with this service comes from the network operators ability to provide the
intelligence in a meaningful timeline. If the network operator can only provide the intelligence
once the adversary has attacked the IoT business, then monitoring and logging systems
placed in the IoT businesss infrastructure should be able to detect the behaviour. However,
if the network operator is able to notify the business of adversarial behaviour at the network
layer, and can identify which individual subscriber has been emitting anomalous network
traffic, the business may be able to limit exposure of the IoT ecosystem by cordoning off that
single users traffic.
7.2.1 Risk
There are certain technologies that the IoT Service Provider will rely on that cannot be
monitored by the IoT Service Provider. One such technology is the communications network
that connects an Endpoint to the Service and Network Ecosystem. Without monitoring
services, the IoT Service Provider will not have a window into the events occurring within the
network, itself. Thus, if an application-level identity A is attempting to compromise a service,
the organization will be unable to identify that Endpoint B is actually the unit that has
connected to the communications network. This gap in information is critical, as the
organization may attribute the attack to identity A rather than a compromised Endpoint B.
7.3 Use a Private APN for Cellular Connectivity

An Access Point Name (APN) is a cellular communications component that connects the
wireless network to the Internet. This point acts as, essentially, a Virtual Private Network
(VPN) between cellular endpoint equipment and service infrastructure that the endpoint must
interact with. A Private APN (sometimes called a Secure APN) is a version of an APN that
has been security hardened to implement several desirable controls:
Limited access restricted to authenticated clients

Firewalling
Endpoint-to-endpoint communication is forcibly disabled
Monitoring services for anomaly detection
Optional security or monitoring services
By restricting access to the APN, an organization can ensure that only authenticated
endpoints are allowed to connect to the service infrastructure made available through the
V1.1 Page 53 of 61
APN. This diminishes the potential for rogue or random wireless clients to connect to the
APN and access restricted services. In addition, it allows the organization to identify which
specific clients are behaving anomalously, which allows the organization to tie negative
behaviour to a specific piece of hardware, or a specific user.
Firewalling ensures that entities attached to the APN from both the client side (Endpoint
Ecosystem) and the service side (Service Ecosystem) are restricted from communicating by
using unapproved channels. This also restricts the ability for an Endpoint to abuse the APN
as a channel to the open Internet, and cordons off traffic to a specific set of approved
services.
Endpoint communications restrictions ensure that rogue endpoints are unable to attack other
endpoints by using the APN as a wide area network. Instead, all communication must pivot
through services approved by the organization. If desired, the organization can disallow
point-to-point communication entirely.
Monitoring services enhance the security improvements that will be made by the
organization in monitoring existing cloud or service infrastructure. By pairing those existing
monitoring services with the APN and network monitoring technologies offered by the
Network Operator, the organization can more easily track down the source of anomalous
behaviour. This enables the organization to more deeply inspect incidents that occur against
its endpoint or service infrastructure. For example, if the application layer indicates that User
A may be compromised, but User Bs equipment is making the authenticated connection to
the APN, the organization will be able to use the APN monitoring services to identify that
User B has potentially compromised User A, or an adversary has compromised both User A
and B.
Network Operators have additional services that can be layered on top of the services
described above. These services will help black-list bad actors in the network, monitor
specific users or sets of users, and can reroute certain types of traffic that may indicate
anomalies. Other options may be available. Engage the Network Operator to determine
which services are right for your organization.
While utilizing all of these services in concert may seem challenging, working with the
Network Operator will simplify the process, and make it simpler to integrate these offerings
into the businesss existing infrastructure. The complexity will come from utilizing the data
effectively, and requires an engineering team that is capable of processing and managing
the data in a reasonable fashion. Some services may incur an additional cost. Determine
what pricing model and services will work best for your organization.
7.3.1 Risk
Without a Private APN, an Endpoint device can connect to almost any service or technology,
including making direct connections to other Endpoints on the APN, or arbitrary service on
the Internet. Since this would allow a compromised Endpoint to interact with almost any
service on the Internet, and could turn the Endpoint into a practical target for acting as a
proxy for attacking more secure networks or services, this recommendation should be
enforced to restrict the ability for Endpoints to make arbitrary, unauthorized connections. It is
much more valuable to the business and to the security of the entire IoT ecosystem when
Endpoints are forced to connect only to approved services.
V1.1 Page 54 of 61
7.4 Define a Third-Party Data Distribution Policy

After security classifications have been defined, and data types have been attributed a valid
classification, and a breach policy has been enacted, a data distribution policy should be
generated. A data distribution policy describes how information should be processed through
technical controls and out to service applications that have been granted permission to
access the data. The permissions model is a part of the data distribution policy, and pairs
with the users ability to create granular data permissions.
While a data distribution policy can be highly descriptive, there are several key elements that
will help define a successful policy:
What level of mutual authentication is required to traffic this data

What confidentiality and integrity of data is required
What ability does the business have to retain the data
What ability does the Partner have to retain the data
If retention is allowed, what period of time may the data be retained for
What level of storage security must be applied to the data
What access security classification must be applied to the data
7.4.1 Risk
Data distribution policies enforce security requirements on partners who may not adhere to
the same level of security internally as the IoT Service Provider does. Since the IoT Service
Provider cannot control the security a partner has implemented in their internal services and
network, the IoT Service Provider can only enforce that data contributed to a partner is
trafficked in a secure manner. Without this definition, the partner can enforce insecure
configurations that may expose user data to adversaries while the data is still under the
control of the IoT Service Provider. By enforcing stringent security controls for the
communications channel, the IoT Service Provider proves it is doing everything it can do to
enforce security until the data is out of its control.
7.5 Build a Third-Party Data Filter

Accepting dynamically generated data, such as advertisements, from a Partner requires a
certain level of presumption regarding the quality and security of the data. Instead of making
presumptions and applying the data to the presentation layer, the engineering team must
take steps to ensure that the data distributed from the service application to or from a partner
is well formed and does not contain potentially malicious content.
To do this, the engineering team should consider the following model:
Does the data fit the format the Partner outlined for the data model
Is the data well-formed
Does the data represent a polymorphic object that could be misinterpreted by the
client
Will the data affect the way the client renders the presentation layer
V1.1 Page 55 of 61
Will the data affect how the client interprets the presentation layer
Does the data entice or request the user to perform a behaviour that would weaken
security
Does the data spoof or impersonate a component (password input field) of the client
GUI
Reject any data that doesnt fit an approved model. Notify administration immediately on
detection of such data, and include as many metrics as possible regarding the origin and
format of the data. Log a sample, if possible, in a secure database.
7.5.1 Risk
Dynamically generated data from third parties could contain malware, inappropriate content,
or other undesirable data, either intentionally or unintentionally. Without an ingress filter
shaped toward the definition of the third party service, the organization can risk accidentally
allowing malware or other malicious content to reach the end user. This may result in system
compromises, or simply lost customers, due to the side effects of such data.
V1.1 Page 56 of 61
8 Low-Priority Recommendations
Low priority recommendations encompass the set of recommendations that apply to risks
that are extremely costly to combat, or are unlikely to affect the endpoint design. While these
recommendations are valuable, and the information detailed within the recommendations is
important, the mitigation or remediation strategies discussed may be out of scope with
respect to the business. Evaluate each recommendation and determine whether the risks
described are relevant or important to the business and its customers. If the customers
require these risks to be addressed, apply the recommendations.
8.1 Rowhammer and Similar Attacks

Some implementations of modern RAM technology such as Dynamic Random Access
Memory (DRAM) and Static Random Access Memory (SRAM) are vulnerable to errors that
can be provably induced by certain memory access sequences. Abusing this type of error
can result in the alteration of a specific bit, or bits, in predictable areas of memory. A
successful exploit of this condition can alter bits in memory that represent types of privilege
denoted by software.
In other words, if exploited correctly, an adversary can elevate their privileges from one user
to another user by manipulating a hardware flaw in modern implementations of DRAM or
SRAM. Many modern implementations of DRAM and SRAM have been found provably
exploitable through this vulnerability. However, it requires the ability to execute code on the
local system in order to create the memory access sequences capable of triggering this bug.
And yet, it may be possible to trigger this type of behaviour remotely through runtime
languages such as sandboxed GoLang, Python, Erlang, and more. However, the
preciseness of these types of attacks has not yet been documented, and is highly
improbable to work effectively as an exploit.
This attack must be resolved at the hardware level. However, engineers can mitigate the risk
of abuse by disallowing clients from executing code, even through a virtual machine or
runtime, on a given service. By restricting this capability, engineers will be able to stop
adversaries from creating the memory access sequences that are required in this attack.
8.1.1 Risk
Without sufficient guards against this kind of attack, adversaries may be able to remotely
elevate privilege or execute arbitrary code against a target host. It should be noted, however,
that a successful attack requires an extremely deep knowledge of the hardware, operating
system, attack vector, and other factors that make this attack unlikely and rare.
8.2 Virtual Machine Compromises

Modern service infrastructure often utilizes virtual machines to deploy services on demand.
While this model has proved extremely convenient and easy to deploy with, the problem with
this methodology is the security of the overall infrastructure. While the engineering team may
succeed in deploying a well thought-out architecture, the organization that manages and
deploys the virtual infrastructure may not be as successful.
V1.1 Page 57 of 61
One major concern of deploying in virtual server environments is the ability for hosts to be
compromised, or for servers (virtual guests) to intercept the data of other guests running on
the same infrastructure.
While these attacks are valid concerns that should be evaluated by the IoT Service Provider,
they often take a large amount of skill and time to perfect. Thus, it is a possibility that an
attack may occur, but it will likely be a rare event. However, if the service infrastructure isn't
well guarded, it will be possible that adversaries may be able to compromise administrative
access to the virtual machines. This kind of a breach may not require a high amount of skill
to succeed.
One way to combat this issue is with server provisioning. This process will ensure that each
server is encoded with a unique set of cryptographic keys. If this process is followed, any
compromise to a single server can be limit to that single server.
8.2.1 Risk
The risk of not accommodating for this type of attack may leave the service infrastructure
vulnerable to many types of attacks. Server impersonation using keys accessible from
the service infrastructure, data exfiltration, privacy compromise, and user
impersonation may be possible.
8.3 Build an API for Users to Control Privacy Attributes

All users must be able to control what information they offer to third parties, through service
APIs. The information should be classified into types of data, and attributed with security
classifications. Users should be able to retrieve the types of data and classifications that are
used in the modelling of their account. The user should be able to apply constraints to the
types of data, to allow them to grant or revoke access to this data to Partners.
This can come in the form of an authenticated API, or a GUI that allows simple Yes or No
controls on a general, and per-Partner basis.
8.3.1 Risk
Without the ability for users to control what data they contribute to an IoT Service Provider,
they run the risk of their data being exposed in the event of a security breach either at the
Service Provider, or one of the partners the Service Provider uses. Since certain users are at
much higher risk than others, each user should be able to tune their privacy restrictions
according to their personal needs. Making this interface available helps to ensure that the
capability is there. The user must take it upon themselves to adjust the controls to suit their
needs.
8.4 Define a False Negative/Positive Assessment Model

While false positive analysis is an extremely complex topic, there is a simple way to identify
whether a technology is more likely to present false positives. This is by evaluating the
following items:
Is the data source trustworthy

Can the data source be tampered with or spoofed
Is the data source from the analogue domain
V1.1 Page 58 of 61
Can the data be corroborated from multiple points of origin

Do the corroborating data sources exist on the same endpoint system
Are corroborating data sources easy to tamper with or spoof
Are tools readily available to manipulate the data source
What level of expertise or cost is required to manipulate the data source
Is the device attached to the data source trustworthy
All of these attributes, and more, can be used to evaluate whether data is trustworthy. This is
extremely important, as critical decisions that affect the physical world can result in
potentially harmful effects. It is imperative that the engineering team create a model for
trustworthiness and apply it to each data source involved in making critical decisions. If the
weight of the data source is such that it cannot be trusted, the most rational, and safest,
action should be taken.
It is important to note that the engineering team is not the only entity that must make this
kind of decision. The business leadership, the lawyer team, and the insurance team should
be involved in the determining the correct reaction in potentially dangerous scenarios.
Engineers must then encode the correct decision making process into the technology in a
verifiable and reproducible way.
This process is highly challenging as it demands the attention of the entire organization on
how the technology should react in critical scenarios. Trustworthiness is a challenging
attribute to apply to a piece of technology, especially an embedded technology.
8.4.1 Risk
Without an assessment model for false positives, engineers may spend too much time
analysing benign events while more important events are occurring. This may result in
increased risk of the metrics analysed by the organization do not provide clear direction as to
what types of events are occurring in production. This devalues the logging and monitoring
infrastructure, and negates the organizations ability to use these expensive resources to its
benefit.
V1.1 Page 59 of 61
9 Summary
In summary, almost every security risk in an IoT product or service can be combatted by a
well-defined architecture, intelligence to identify risks before and during security related
events, and policies and procedures to handle such events. By analysing which high-level
security concepts are important to the IoT Service Provider, frequently asked security
questions can be reviewed. This should guide the engineering team toward which
recommendations are most relevant to resolve gaps in their security architecture.
As the team progresses in its architectural definition, it can review standalone

recommendations as their security questions and concerns become more unique to their
own implementation.
Overall, every engineering team will face very similar risks. It is imperative that the
organization choose to share their concerns with their peers to build common a
knowledgebase for both risks and remediation strategies. Together, our organizations can
build both technology and knowledge to assist each other in building security into the future
of IoT.
V1.1 Page 60 of 61
Annex A Document Management
A.1 Document History

Authority Company
GSMA
&
Don A. Bailey
Lab Mouse Security
1.1 07-Nov-2016 References to GSMA IoT PSMC
Security Assessment scheme Ian Smith
added. GSMA
Minor editorial corrections.
A.2 Other Information

Type Description
Document Owner GSMA Internet of Things Programme
V1.1 Page 61 of 61
Official Document CLP.13 - IoT Security Guidelines Endpoint Ecosystem
IoT Security Guidelines Endpoint Ecosystem

Version 1.1
07 November 2016

Copyright Notice
Disclaimer
Antitrust Notice
V1.1 Page 2 of 84
Table of Contents
1 Introduction 5
1.1 Introduction to the GSMA IoT Security Guideline Document Set 5
1.4 Definitions 6
1.5 Abbreviations 8
1.6 References 9
2 The IoT Endpoint Security Challenge 11
2.1 Low Power Consumption 11
2.2 Low Cost 11
2.3 Long-Lived (>10 years) 11
2.4 Physically Accessible 11
3 The IoT Endpoint Model 12
3.1 The Lightweight Endpoint 12
3.2 The Complex Endpoint 13
3.3 The Gateway (or Hub) 13
3.4 The Overarching Model 14
4 The Security Model 15
4.1 Network Communications Attacks 15
4.2 Accessible Network Services Attacks 16
4.3 Console Access Attacks 16
4.4 Local Bus Communications Attacks 17
4.5 Chip Access Attacks 18
5 Frequently Asked Security Questions 19
5.1 How do we Combat Cloning? 19
5.2 How should I Secure the Endpoint Identity? 19
5.3 How do I Reduce the Impact of an Attack Against the Trust Anchor? 20
5.4 How do I Reduce the Probability of Endpoint Impersonation? 20
5.5 How do I Disallow the Ability to Impersonate Services or Peers? 20
5.6 How do I Disallow Tampering of Firmware and Software? 21
5.7 How do I Reduce the Possibility of Remote Code Execution? 21
5.8 How do I Disallow Unauthorized Debugging or Instrumenting of the
Architecture? 21
5.9 How should I handle Side-Channel Attacks? 22
5.10 How should I Implement Secure Remote Management? 22
5.11 How do I Detect Compromised Endpoints? 23
5.12 How do I Securely Deploy a Device Without a Back-End Connection? 23
5.13 How do I Ensure my Consumers Privacy? 23
5.14 How do I Ensure User Safety While Enforcing Privacy and Security? 23
5.15 What Issues Should I Not Expect To Resolve? 24
6 Critical Recommendations 25
6.1 Implement an Endpoint Trusted Computing Base 25
V1.1 Page 2 of 84
6.2 Utilize a Trust Anchor 29

6.3 Use a Tamper Resistant Trust Anchor 31
6.4 Define an API for Using the TCB 31
6.5 Defining an Organizational Root of Trust 32
6.6 Personalize Each Endpoint Device Prior to Fulfilment 34
6.7 Minimum Viable execution Platform (Application Roll-Back) 35
6.8 Uniquely Provision Each Endpoint 36
6.9 Endpoint Password Management 37
6.10 Use a Proven Random Number Generator 38
6.11 Cryptographically Sign Application Images 39
6.12 Remote Endpoint Administration 40
6.13 Logging and Diagnostics 40
6.14 Enforce Memory Protection 41
6.15 Bootloading Outside of Internal ROM 42
6.16 Locking Critical Sections of Memory 42
6.17 Insecure Bootloaders 43
6.18 Perfect Forward Secrecy 44
6.19 Endpoint Communications Security 45
6.20 Authenticating an Endpoint Identity 46
7 High Priority Recommendations 47
7.1 Use Internal Memory for Secrets 47
7.2 Anomaly Detection 48
7.3 Use Tamper Resistant Product Casing 49
7.4 Enforce Confidentiality and Integrity to/from the Trust Anchor 51
7.5 Over the Air Application Updates 52
7.6 Improperly Engineered or Unimplemented Mutual Authentication 53
7.7 Privacy Management 55
7.8 Privacy and Unique Endpoint Identities 56
7.9 Run Applications with Appropriate Privilege Levels 56
7.10 Enforce a Separation of Duties in the Application Architecture 57
7.11 Enforce Language Security 58
8 Medium Priority Recommendations 59
8.1 Enforce Operating System Level Security Enhancements 59
8.2 Disable Debugging and Testing Technologies 60
8.3 Tainted Memory via Peripheral-Based Attacks 61
8.4 User Interface Security 62
8.5 Third Party Code Auditing 63
8.6 Utilize a Private APN 63
8.7 Implement Environmental Lock-Out Thresholds 64
8.8 Enforce Power Warning Thresholds 65
8.9 Environments Without Back-End Connectivity 67
8.10 Device Decommissioning and Sunsetting 67
8.11 Unauthorized Metadata Harvesting 69
9 Low Priority Recommendations 70
V1.1 Page 3 of 84
9.1 Intentional and Unintentional Denial of Service 70

9.2 Safety Critical Analysis 71
9.3 Defeating Shadowed Components and Untrusted Bridges 71
9.4 Defeating a Cold Boot Attack 73
9.5 Non-Obvious Security Risks (Seeing Through Walls) 74
9.6 Combating Focused Ion Beams and X-Rays 75
9.7 Consider Supply Chain Security 76
9.8 Lawful Interception 77
10 Summary 79
Annex A Example Using Generic Bootstrap Architecture 80
Annex B Tutorial on use of UICC cards in an IoT Service 82
Annex C Document Management 83
C.1 Document History 83
C.2 Other Information 83
V1.1 Page 4 of 84
1 Introduction
1.1 Introduction to the GSMA IoT Security Guideline Document Set
This document is one part of a set of GSMA security guideline documents that are intended
to help the nascent Internet of Things (IoT) industry establish a common understanding of
IoT security issues. The set of non-binding guideline documents promotes methodology for
developing secure IoT Services to ensure security best practices are implemented
recommended that the overview document CLP.11 IoT Security Guidelines Overview
Document [1] is read as a primer before reading the supporting documents CLP.12 [2] and
CLP.13 [3] (this document).
CLP.11
Document CLP.14
IoT Security
CLP.12 CLP.13
+ Guidelines for
Network
Ecosystem Ecosystem
Figure 1 - GSMA IoT Security Guidelines Document Structure


V1.1 Page 5 of 84

This document shall be used to evaluate the components of an IoT Service from the IoT
Endpoint Device perspective. An Endpoint, from an IoT perspective, is a physical computing
device that performs a function or task as a part of an Internet connected product or service.
An Endpoint, for example, could be a wearable fitness device, an industrial control system,
an automotive telematics unit or even a personal drone unit. All technologies used to drive
the physical device shall be evaluated for security risks. The result is a practical set of
design guidelines that allow the reader to identify and remediate almost all potential risks to
the IoT Service.
The scope of this document is limited to recommendations pertaining to the design and
implementation of IoT Endpoint Devices.
This document is not intended to drive the creation of new IoT specifications or standards,
but will refer to currently available solutions, standards and best practice.

IoT Service Providers - Enterprises or organisations who are looking to develop new
IoT Device Manufacturers - provide IoT Devices to IoT Service Providers to enables
IoT Services.
IoT Developers who build IoT Service on behalf of IoT Service Providers.
Network Operators who provide services to IoT Service Providers.
1.4 Definitions
Term Description
Identifier of a network connection point to which an Endpoint device
Access Point Name attaches. They are associated with different service types, and in many
cases are configured per network operator.
A hacker, threat agent, threat actor, fraudster or other malicious threat to an
IoT Service. This threat could come from an individual criminal, organised
Attacker crime, terrorism, hostile governments and their agencies, industrial
espionage, hacking groups, political activists, hobbyist hackers,
researchers, as well as unintentional security and privacy breaches.
A network of remote servers on the internet that host, store, manage, and
Cloud
process applications and their data.
V1.1 Page 6 of 84
Term Description
This Endpoint model has a persistent connection to a back-end server over a
Complex Endpoint long-distance communications link such as cellular, satellite, or a hardwired
connection such as Ethernet. See section 3.
Embedded SIM A SIM which is not easily accessible or replaceable, is not intended to be
removed or replaced in the device, and enables the secure changing of
profiles.
Endpoint An IoT Endpoint is a physical computing device that performs a function or
task as part of an Internet connected product or service. See section 3 for a
description of the three common classes of IoT devices, and examples of
each class of Endpoint.
devices and appliances connected to the Internet through multiple networks.
These devices include everyday objects such as tablets and consumer
Internet of Things
electronics, and other machines such as vehicles, monitors and sensors
equipped with machine-to-machine (M2M) communications that allow them
to send and receive data.
Any computer program that leverages data from IoT devices to perform the
IoT Service
service.
The set of services, platforms, protocols, and other technologies required to
IoT Service
provide capabilities and collect data from Endpoints deployed in the field.
Ecosystem
See CLP.11 [1] for further information.
IoT Service Enterprises or organisations who are looking to develop new and innovative
Provider connected IoT products and services.
The operator and owner of the communication network that connects the IoT
Network Operator
Endpoint Device to the IoT Service Ecosystem.
A set of cryptographic policies and procedures that govern how identities,
Organizational Root
applications, and communications can and should be cryptographically
of Trust
secured.
Service Access A point of entry into an IoT Services back end infrastructure via a
Point communications network.
Subscriber Identity The smart card used by a mobile network to authenticate devices for
Module connection to the mobile network and access to network services.
In cryptographic systems with hierarchical structure, a trust anchor is an
Trust Anchor
authoritative entity for which trust is assumed and not derived.
A Trusted Computing Base (TCB) is a conglomeration of algorithms, policies,
and secrets within a product or service. The TCB acts as a module that
allows the product or service to measure its own trustworthiness, gauge the
authenticity of network peers, verify the integrity of messages sent and
Trusted Computing
received to the product or service, and more. The TCB functions as the base
Base
security platform upon which secure products and services can be built. A
TCBs components will change depending on the context (a hardware TCB
for Endpoints, or a software TCB for cloud services), but the abstract goals,
services, procedures, and policies should be very similar.
V1.1 Page 7 of 84
Term Description
An environment which runs alongside a rich operating system and provides
Trusted Execution security services to that operating system. There are multiple technologies
Environment (TEE) which can be used to implement a TEE, and the level of security achieved
varies accordingly.
A Secure Element Platform specified in ETSI TS 102 221 that can support
multiple standardized network or service authentication applications in
UICC
cryptographically separated security domains. It may be embodied in
embedded form factors specified in ETSI TS 102 671.
1.5 Abbreviations
Term Description
AC Alternating Current
BT Bluetooth
CPE Customer Premises Equipment
CPU Central Processing Unit
EEPROM Electrically Erasable Programmable Read-Only Memory
eUICC Embedded UICC
FIB Focused Ion Beam
GBA Generic Bootstrapping Architecture
GPS Global Positioning System
LAN Local Area Network
BLE Bluetooth Low Energy
ISM Industrial, Scientific and Medical
MCU MicroController Unit
NVRAM Non-Volatile Random Access Memory
PAN Personal Area Network
PSK Pre-Shared Key
RAM Random Access Memory
ROM Read Only Memory
SCADA Supervisory Control And Data Acquisition
SPI Serial Peripheral Interface
V1.1 Page 8 of 84
Term Description
SSH Secure Shell
SRAM Static Random Access Memory
TCB Trusted Computing Base
TTL TransistorTransistor Logic
UART Universal Asynchronous Receiver/Transmitter
1.6 References
[1] CLP.11 IoT Security Guidelines Overview Document
[2] CLP.12 IoT Security Guidelines for IoT Service Ecosystem
[3] CLP.13 IoT Security Guidelines for IoT Endpoint Ecosystem
[4] CLP.14 IoT Security Guidelines for Network Operators
OMA FUMO OMA Firmware Update Management Object
[5]
www.openmobilealliance.org
na ST-LINK/V2 in-circuit debugger/programmer
[6]
http://www.st.com/
[7] na
n Mobile IoT Initiative
a http://www.gsma.com/iot/mobile-iot-initiative/
na Nmap Security Scanner
[8]
https://nmap.org/
CLP.03 IoT Device Connection Efficiency Guidelines
[9]
http://www.gsma.com/iot/iot-connection-efficiency-guidelines-v4/
na Federal Information Processing Standards
[10]
www.nist.gov/itl/fips.cfm
na EMVCo
[11] n
www.emvco.com/
na SIM Alliance - Open Mobile API
[12]
simalliance.org/key-technical-releases/
GPD_SPE_013 GlobalPlatform Secure Element Access Control
[13]
GPD_SPE_024 GlobalPlatform Trusted Execution Environment API Specification
[14]
GPC_SPE_034 GlobalPlatform Card Specification
[15]
www.globalplatform.org/specificationscard.asp
ISO/IEC 29192-1 Information technology -- Security techniques -- Lightweight
[16] cryptography
www.iso.org/obp/ui/#iso:std:iso-iec:29192:-1:ed-1:v1:en
[17] TS 33.220 Generic Authentication Architecture (GAA); Generic Bootstrapping
V1.1 Page 9 of 84

Architecture (GBA)
www.3gpp.org
Generic Authentication Architecture (GAA); Access to network
application functions using Hypertext Transfer Protocol over Transport
[18] TS 33.222
Layer Security (HTTPS)
www.3gpp.org
[19] CLP.17
http://www.gsma.com/iot/iot-security-assessment/
V1.1 Page 10 of 84
2 The IoT Endpoint Security Challenge

The security challenge presented by an IoT Service is, in many cases, directly related to the
specific characteristics of the IoT Endpoint employed by the service. For example, many IoT
Endpoints have the following characteristics which have particular security challenges
associated to them:
2.1 Low Power Consumption

Low power consumption may be required to achieve long battery life (several years)
for a remote inaccessible Endpoint without a permanent power supply or because the
device has a permanent, but limited, power supply, e.g. solar energy supply.
Low power consumption Endpoints can usually only undertake computationally
simple cryptographic operations (for example the Endpoint may only support the
lightweight cryptographic operations defined within ISO/IEC 29192 [16]) due to the
high power consumption requirements associated with more advanced cryptographic
operations and may only support limited bandwidth communications again limiting
cryptographic capability.
2.2 Low Cost

The business case for many IoT Services demands that the cost of the IoT Endpoint
be kept low. This often results in the device containing low processing capability,
small amounts of memory and constrained operating system. The net result is that
the device may be unable to perform internet-grade cryptography.
2.3 Long-Lived (>10 years)

Many Endpoints, particularly for civic and industrial applications (e.g. a smart gas
meter), must be long lived. This presents a challenge because the cryptographic
design choices made when the device is designed will have to be robust for the
lifetime of the device. For example the processing power per $ available to an
Attacker over this 10 year period is likely to have increased 16 times whereas the
capabilities of the device is likely to remain static.
Management of long lifetime devices is also a challenge particularly if a security
vulnerability is found that cant be patched within the IoT Endpoint.
2.4 Physically Accessible

Many IoT Endpoints are physically accessible to the Attacker. All hardware
components and interfaces on these Endpoints are therefore potentially subject to
attack and must be secured by the developer.
The net result of the above is in many IoT Services, the IoT Endpoints are not directly
connected to wide area communications networks and many IoT Endpoints have no Internet
Protocol (IP) capabilities. For example, an IoT Endpoint may use an industrial, scientific and
medical (ISM) radio transceiver to transfer data to a local IoT Service Gateway that then
takes the data and transmits it to the communications network using IP, complicating the
process of securing the end-to-end communication.
V1.1 Page 11 of 84
Depending on the capabilities of the IoT Endpoint and the security risks associated with it,
different security methods with varying degrees of complexity may need to be applied as
explained in the rest of this document.
3 The IoT Endpoint Model

Once considered a set of vastly disparate technologies, interacting with the physical world
and connecting to a server somewhere on the Internet for guidance and submission of
metrics, the IoT Endpoint model has changed dramatically. In modern engineering, IoT
technology has collapsed into a predictable model composed of only several variants. The
IoT Endpoint is becoming more predictable as well, and is expected to take on one of only
several manifestations:
The Lightweight Endpoint

The Complex Endpoint
The Gateway (or Hub)
In the diagram below some common IoT Endpoint configurations are shown:
Figure 2 - Example IoT Endpoint Configurations
3.1 The Lightweight Endpoint

This type of Endpoint is typically a sensor or simple physical device, such as a light switch or
a door lock that has few functions. Its goal is to serve a singular physical purpose, and to
provide metrics to the Service Ecosystem or to the consumer. It commonly uses a very
cheap processing unit, possibly an eight-bit microcontroller, and a short-distance Personal
Area Network (PAN) or capillary protocol for connectivity, such as Bluetooth Low Energy
(BLE), Thread, or Zigbee. It is usually low power, and may operate off of a coin cell battery,
solar power, or a small lithium polymer battery. These devices are typically connected to the
Service Ecosystem via IoT service Gateways and Customer Premises Equipment Gateway
as shown in Example Endpoint Config#3 in figure 2.
V1.1 Page 12 of 84
Examples of Lightweight Endpoints are:
Wearables
Home security sensor Endpoints
Proximity beacons
Non-cellular capillary devices
Due to the low cost of lightweight Endpoints, the security technologies available to these
devices is minimal. Security technologies that require a significant amount of current draw,
cost, or space on the circuit board are not usually available to these systems. However,
lightweight Endpoints can still use cost effective and small trust anchors to implement robust
security framework.
3.2 The Complex Endpoint

This Endpoint model typically has a persistent connection to a back-end server over a long-
distance communications link such as cellular (see Example Endpoint Config#1 in figure 2)
connects using Wi-Fi or Ethernet via a Customer Premises Equipment Gateway (see
Example Endpoint Config#2 in figure 2).. The device may have a rudimentary processor in
it, even an eight-bit microcontroller, but is capable of running a more robust processing unit
as it is either directly connected to an Alternating Current (AC) power source or it contains a
battery and has regular access to a battery recharging system. Some Complex Endpoints
communicate over capillary protocols, but require more power to run the local application
efficiently, such as a streaming audio device.
Examples of Complex Endpoints are:
IoT connected lighting systems

Appliances such as refrigerators or washing machines
Industrial control systems (e.g. SCADA)
Retro-fit OBD2 cellular connected car tracking and monitoring devices
Complex Endpoints are capable of more current draw, typically implement more robust
processors, and have more space on the circuit board available for security technologies. As
a result, much more can be done with Complex Endpoints. These devices can use almost
any kind of Trust Anchor. As a result, they are easily able to implement a Personalized Pre-
Shared Key (PSK) or asymmetric Trusted Computing Base (TCB) model as described later
in this document.
3.3 The Gateway (or Hub)

A gateway is a device, typically connected to dedicated power source, which typically
manages the communication between lightweight Endpoints and the back-end systems that
drive them. The gateway manages long-distance communication links, such as cellular,
satellite, fixed-line, fibre, or Ethernet. It accepts commands from the back-end systems living
in the Service Ecosystem, and translates them to messages consumable by the light-weight
Endpoints. Endpoint
While the primary function of an IoT Gateway is to route messages to and from lightweight
Endpoints, it is also capable of performing critical tasks, such as:
V1.1 Page 13 of 84
Device discovery
Network driver deployment
Management functionality
Runtime monitoring
Authentication and Security such as GBA or TLS setup
While Gateways are technically Endpoints, they may not necessarily be managed by the
end-user, and may be managed by the IoT Service Provider or Network Operator (see
below). Regardless of this, Gateways may also be engineered as Complex Endpoints to
make more efficient use of distributing an uplink to multiple Lightweight Endpoints in a
localized network.
Like the Complex Endpoints, Gateways are capable of more processing power, current
draw, and typically have more space available on the circuit board. This allows IoT
Gateways to implement complex Trusted Computing Base solutions, and technologies such
as GBA authentication clients, with relative ease.
These attributes of the Gateway also enables them to incorporate multiple communications
technologies to route messages between disparate types of networked devices. This
enables communication between endpoints that normally would be unable to exchange
messages in an effective manner. In this fashion, Gateways function as an aggregation point
for devices within the local ecosystem, allowing them to communicate with each other and, if
necessary, the Network and Service Ecosystems.
There are typically two types of Gateway an IoT Service Gateway and Customer
Premises Equipment (CPEs) Gateway. The difference is explained below:
1. An IoT Service Gateway is provided by the IoT Service Provider. It may be owned
by the end user but is typically managed by the IoT Service Provider. Such a gateway
is typically used as a hub to connect lightweight Endpoints to the service ecosystem
(either directly via a fixed/cellular connection, or via a CPE gateway), where the end-
user buys a managed service from an IoT Service Provider.
2. A CPE Gateway is provided by a Network Operator. This is typically a broadband
router connected to the internet by cellular or fixed networks. This may be used in
residential or enterprise environments. In this configuration, the gateway is usually
managed and configured by the Network Operator.
3.4 The Overarching Model

Regardless of which type of Endpoint is being evaluated or designed, they all have similar
subcomponent models from a hardware and logistic perspective:
A Central Processing Unit (CPU) must execute application code

The CPU must load/store data and executable code from/to persistent storage
The CPU must compute data in temporal storage
A Trusted Computing Base must be used to authenticate the environment
The device must communicate with its IoT ecosystem
It is notable that lightweight Endpoints have less storage and computation capacities than
Complex Endpoints or Gateways. They typically have less security capability as well.
V1.1 Page 14 of 84
The most important aspect of the overarching model is that each type of Endpoint device
has one primary job: to define a reliable, high quality, and secure platform for executing a
particular application. In other words, similar to more complex computing platforms such as
smart-phones, Cloud servers, and mainframes, before a high-quality application can be ran
reliably or interact securely with its peers, the engineering team must ensure the hardware
presents a trustworthy platform to the application.
IoT Endpoints, by nature, participate in a network of other Endpoints. They are not
standalone devices that perform an action without the influence or participation of an
oversight service. To increase the trustworthiness of a given device, and diminish the
potential for liability due to gaps in security or reliability, every Endpoint must be designed
with the idea that trustworthiness in the entire IoT ecosystem begins by the construction of
the Endpoint hardware.
With this perspective in mind, it is clear that even the easiest to develop type of Endpoint
device must behave in a reliable, high quality, and secure manner because it is expected to
participate in a network that could eventually span up to millions of devices in size. The
manner in which a single Endpoint behaves will certainly have an effect on its entire IoT
ecosystem. As a result, engineers must consider the implications of architecture design far
beyond the physical attributes associated with a given embedded device. Engineers must
think in terms of the security, reliability, and quality needs of the entire IoT ecosystem.
4 The Security Model

Security in the Endpoint can be assessed from a component perspective. By evaluating
each component that is required to build any given Endpoint, the engineer and adversary
can build a likely set of attacks that will result in full system compromise without a large
amount of effort.
Using the Overarching Endpoint Model defined above, the components used can be
evaluated from a high level. The high level perspective of each component will direct an
analyst to technologies that are commonly used, and likely to be improperly secured. By
prioritizing these components from the least level of expertise, equipment, and cost required
to succeed, an analyst or adversary can build an attack model that will quickly assess any
given Endpoint for security flaws.
In the Endpoint Ecosystem, there are several threat surfaces that will be investigated by
adversaries depending on their resources, access to infrastructure, and expertise. These
threat surfaces are:
Network Communications
Accessible network services
Console access
Local bus communications
Chip access
4.1 Network Communications Attacks

The first and simplest step in attempting to compromise an IoT Endpoint typically involves
weaknesses in the communications model. Analysts will observe whether the
V1.1 Page 15 of 84
communication model incorporates communications security best practices. If the analyst

can easily capture login credentials, communications tokens, or other identifiers that the
Service Ecosystem will use to identify the Endpoint, they have compromised the device.
This strategy can waver from extremely simple to extremely difficult. The reason for this is
the analyst or adversarys access to the plaintext data passing over the communications
channel. A sufficiently outfitted analyst will already have technology to intercept
communications for BLE, 802.15.4, and other popular protocols. Since observing, or
performing a man-in-the-middle attack against an Endpoints communications typically
requires little to no change to the Endpoint, the adversary is in a highly beneficial position. It
requires very little effort and work to implement this type of attack.
However, if the communications model uses best practices to enforce the confidentiality and
integrity of data, the adversary will have an exponentially difficult time accessing valuable
secrets. This will cause the adversary to move on to the next easiest attack model.
4.2 Accessible Network Services Attacks

The next step in attacking an IoT Endpoint is an evaluation of the network services that are
open. In the first step, outbound messages emanating from the Endpoint are captured to
identify whether immediately usable secrets are accessible in the messages. This allows an
adversary to reduce the amount of work required in extracting secrets from the Endpoint,
itself. If the outbound communications security model is sound, network services are
scanned to evaluate whether the Endpoints operating system can be accessed, or
instrumented, from the network.
An assessment will be performed with a tool such as NMap [8] to determine whether network
ports are open. If the network topology isnt IP capable, which is common in BLE or IEEE
802.15.4 networks, the adversary can still use readily accessible tools to connect to the
Endpoint over the appropriate radio protocol.
The adversary will then attempt to send messages to the Endpoint to determine if the
Endpoint can be manipulated into either executing commands, or providing remote-console
access to the operating system. A common method is assessing whether a network login
interface, such as Secure Shell (SSH) or telnet is available. If default login credentials are
used, the adversary may be able to log into the Endpoint. This will allow the adversary to
manipulate the local operating system, and potentially abuse local vulnerabilities to escalate
privileges and extract secrets from the device.
Another common example includes the abuse of poorly designed web services, where
commands can be injected over Common Gateway Interface (CGI) scripts that dont
adequately strip control characters from user input fields, resulting in code execution on the
local operating system.
4.3 Console Access Attacks

Console access isnt exactly an attack, its a strategy. Typically, consoles need to be
enabled on Endpoints to provide developers and Quality Assurance (QA) technicians with
the ability to diagnose anomalies in hardware or software. However, the information provided
from a console is very valuable to an adversary. In addition, a console may provide an
adversary with the ability to log into the Endpoint system both locally and remotely.
V1.1 Page 16 of 84
Typically, local hardware consoles can be found on Endpoint devices by:
Looking for a 5 pin header on the circuit board indicating a TTL serial port
Looking up the specifications for the CPU or MCU and identifying the UART pins
A multi-meter can be used to identify a TTL port, as the pins will adhere to the typical voltage
specification for TTL. Alternatively, a logic analyser can be used to guess the baud-rate of
any serial data traversing hardware pins. The analyst will quickly be able to discern whether
a console is available on the local hardware.
In many cases, simply accessing a console port allows an analyst to have direct access to a
command prompt on the Endpoint device. In other cases, login credentials are required, but
are typically guessable. If another individual on the Internet has identified the login
credentials, and all Endpoint login credentials are the same, all an analyst has to do is
perform a Google search online to see if someone else has posted the credentials.
Remote console access can be acquired through diagnostic networking protocols, console
access protocols (e.g. SSH or telnet), or other means. These access methodologies should
be evaluated to determine whether an adversary can manipulate the access channel,
thereby granting the adversary access to a remote console.
4.4 Local Bus Communications Attacks

If a command prompt cannot be obtained through a console, the adversary or analyst will
need to start inspecting hardware to determine if the Endpoint is easily compromised. This
takes many different forms, but there are easy steps that will be taken:
Is writable media present and alterable

Are cryptographic secrets passed in the clear over hardware busses
Can messages be injected into the hardware circuit that influence the behaviour of
the application or operating system in the adversarys favour
The simplest attack is identifying whether writable media is present. This could be media that
is simple to alter, such as a writable external memory (SD/MMC) card. Or, an NVRAM chip
or EEPROM can be altered with application or configuration changes to allow command
prompt access, or access to securely stored tokens.
If this vector is properly secured, the analyst will determine if cryptographic secrets are
passed in the clear over hardware busses. This could involve using a logic analyser to
intercept messages between an EEPROM and a CPU, a microcontroller and a SPI-
connected network adapter, or other attacks. These attacks can range from extremely
simple and fast, to complex and expensive, depending on the complexity of the attack and
the technology abused.
If the adversary cannot intercept valuable secrets using the above method, they can attempt
to inject messages into hardware busses to change the behaviour of an application running
on the Endpoint. This is a difficult attack that requires a high degree of expertise, equipment,
and the ability to evaluate the application-specific data and its context.
V1.1 Page 17 of 84
4.5 Chip Access Attacks

If the attacks above are too complex or expensive, the adversary must move on to even
more complex attacks against the hardware. This typically involves abusing the security of
the chip, or the various components on the circuit board. This may include:
Decapping the microcontroller or CPU

Extracting secrets from internal EEPROM or NVRAM
Intercepting internal SRAM messages
Performing X-Ray analysis or FIB reverse engineering
All of these attacks require a high degree of skill, electronic engineering knowledge, and
expensive equipment. While most organizations will not need to fear an Attacker utilizing
these methodologies to reverse engineer their products, it is still an important possibility to
consider. The reason is that these attacks only need to be performed one time if the
Endpoint devices are not provisioned with unique cryptographic secrets.
If they are not provisioned with unique cryptographic secrets, one attack in this class will
extract secrets that can affect the entire product line. That is a significant risk, because if the
data is released to the public for any reason, the technology will be subject to attack and
abuse until a patch is released, if one can be released.
V1.1 Page 18 of 84
5 Frequently Asked Security Questions

Endpoint security is broken down into recommendations by priority in this document. But, for
practical use, it is more beneficial to evaluate recommendations from a practical starting
point. Engineers typically start building a list of recommendations based on a technological
or business-influenced goal. This section outlines common goals from an Endpoint
perspective, and which recommendations are relevant toward achieving those goals.
5.1 How do we Combat Cloning?

Protecting intellectual property is an important goal for modern businesses. The hardware,
firmware, and communications technologies used to build an Endpoint product take time,
expertise, and finances that companies dont want to easily build another less scrupulous
companys brand or business. However, no matter what a company does, someone can use
the exact same hardware components to build a look-a-like rip off or clone of a given
product. There is nothing the company can do to prevent this outside of legal contracts and
partnerships. However, there are cost-effective ways to prevent someone from using such a
clone.
Building authentication into the Endpoint communications will ensure that each Endpoint is
cryptographically proven to be manufactured by the IoT Service Provider. Whenever the
back-end services, or a peer Endpoint, communicates with an Endpoint device, it will be able
to differentiate between a valid Endpoint and a clone by forcing the Endpoint to authenticate
itself. If the device cannot do so, the peer or service can reject the Endpoint. This requires
the following recommendations to work:
Authenticating an Endpoint Identity

Improperly Engineered or Unimplemented Mutual Authentication
5.2 How should I Secure the Endpoint Identity?

In order to properly authenticate an Endpoint, the engineer must be able to trust the
Endpoints cryptographic identity. This is more complex than it seems, and requires a
combination of process, policy, and technology to achieve the goal. This is further elaborated
in the Implement a Trusted Computing Base recommendation, but the way in which
authentication tokens are encoded on an Endpoint will determine how secure the overall
system is.
In many Endpoint architectures, an adversary can simply copy cryptographic tokens (if there
are any) from the target device in order to impersonate it. If each Endpoint manufactured by
the IoT Service Provider utilizes the same set of cryptographic tokens, the adversary may be
able to impersonate any device simply by compromising one single set of tokens.
Thus, building the proper TCB requires the following recommendations:
Implement a Trusted Computing Base

Utilize a Trust Anchor
Use a Tamper Resistant Trust Anchor
Utilise an API for the TCB
Use a Proven Random Number Generator
V1.1 Page 19 of 84
Use Tamper Resistant Product Casing

Enforce Confidentiality and Integrity to/from the Trust Anchor
5.3 How do I Reduce the Impact of an Attack Against the Trust Anchor?
It is also important to note that the way a device is manufactured and provisioned has a
drastic effect on the security of an Endpoint in production. The manufacturing process will
determine whether Endpoints are securely encoded with keys. The fulfilment and
provisioning process will determine how an Endpoint is associated with a particular
consumer, and whether the device can be compromised before or after an association is
made.
Consider Supply Chain Security

Personalize Each Endpoint Device Prior to Fulfilment
Uniquely Provision Each Endpoint
Privacy and Unique Endpoint Identifiers
5.4 How do I Reduce the Probability of Endpoint Impersonation?

After cloning of devices for business reasons, a desirable attack from an adversarys
perspective is the impersonation of a person or a particular device. This may or may not be
directly associated with the attack of a particular individual. It could simply be the
impersonation of a device for the purposes of bypassing a security control, such as a
Bluetooth-enabled digital lock.
Regardless of the rationale, combatting this attack can be achieved by using a TCB,
personalization, authentication, and also:

Locking Critical Sections of Memory
5.5 How do I Disallow the Ability to Impersonate Services or Peers?

Every IoT network is composed not only of Endpoint devices, but of network services and
peers. The Endpoints must be authenticated by the services, but the services must also be
authenticated by the Endpoints. This ensures that critical services, such as application
updates, cannot be subverted to further compromise the network.
Endpoint Communications Security

Use a Proven Random Number Generator
Over the Air Application Updates
Improperly Engineered or Unimplemented Mutual Authentication
Unauthorized Metadata Harvesting
V1.1 Page 20 of 84
5.6 How do I Disallow Tampering of Firmware and Software?

Once a root of trust has been established, the Endpoint can authenticate from a trustworthy
component. Doing so allows the Endpoint to establish a base of trust and ensure that the
next stage application has not been altered either unintentionally (through faulty NVRAM, for
example) or intentionally by an adversary. Accomplish this by:
Minimum Viable execution Platform (Application Roll-Back)

Cryptographically Sign Application Images
Bootloading Outside of Internal EEPROM
Insecure Bootloaders
5.7 How do I Reduce the Possibility of Remote Code Execution?

If tampering with physical firmware or software doesnt yield adequate results, the adversary
may move on to more complex attacks, such as code execution against the bootloader or
applications that communicate over bus or network interfaces. If all peers in the network are
authenticated, as depicted earlier in this chapter, it will be far more challenging for an
adversary to inject malicious content. Yet, most devices require some semblance of public
communications to interact with devices from other organizations. Therefore, they may not
be able to adequately enforce restrictions on the origin of data.
Thus, the ingress of data into the computer system from both remote and physical interfaces
must be heavily scrutinized. To limit the potential for exploitation of an application, and limit
exposure once an application is compromised, consider the following:
Enforce Memory Protection

Use Internal Memory for Secrets
Over the Air Application Updates
Run Applications With Appropriate Privilege Levels
Enforce a Separation of Duties in the Application Architecture
Enforce Language Security
Enforce Operating System Level Security Enhancements
User Interface Security
Third Party Code Auditing
5.8 How do I Disallow Unauthorized Debugging or Instrumenting of the

Architecture?
An Attacker with architectural knowledge and access to debugging tools will typically attempt
to instrument standard debugging and diagnostic utilities to gain access to system secrets,
or to alter or inject beneficial code. Restricting an adversarys ability to do this will diminish
the potential for fast and stealthy attacks that may not be detected by a consumer.
Use a Tamper Resistant Trust Anchor
V1.1 Page 21 of 84
Logging and Diagnostics

Anomaly Detection
Disable Debugging and Testing Technologies
User Interface Security
5.9 How should I handle Side-Channel Attacks?

When an adversary is out of typical options, they will look to more esoteric attacks in order to
extract secrets from a device. These attacks evaluate how the hardware behaves in order to
ascertain whether a pattern in behaviour can equate to a value, such as a one or zero, or a
particular instruction. This, over time, will give the analyst the ability to reverse engineer the
data being processed by the embedded system.
Also, the adversary can use expensive analysis technology to extract secrets from the
device, or to build extremely small circuits that bridge connections through security layers in
the silicon. While these attacks are extremely difficult to combat against, there are some
things that the implementer can do to dissuade attacks:

Use Internal Memory for Secrets
Tainted Memory via Peripheral-Based Attacks
Implement Environmental Lock-Out Thresholds
Enforce Power Warning Thresholds
Device Decommissioning and Sunsetting
Defeating Shadowed Components and Untrusted Bridges
Defeating a Cold-Boot Attack
Combating Focused Ion Beams and X-Rays
5.10 How should I Implement Secure Remote Management?

Remote management is a critical part of the IoT Endpoint lifecycle that must be safeguarded
to ensure the channel used for management and administration cannot be abused. This is
not only an issue with unknown third-party adversaries. Internal abuses can occur as well,
either within the consumers circle, or within the IoT Service Provider.
Endpoint Password Management

Remote Endpoint Administration
Logging and Diagnostics
Use a Private APN
V1.1 Page 22 of 84
5.11 How do I Detect Compromised Endpoints?

Depending on the architecture of the Endpoint, it may be nearly impossible to determine if
the hardware or firmware has been tampered with if the device is behaving normally.
However, a compromised device can be detected by anomalous behaviour as long as the
infrastructure is tracking, logging, and alerting when abnormalities are detected. Consider
the following recommendations:
Anomaly Detection
Enforce Power Warning Thresholds
5.12 How do I Securely Deploy a Device Without a Back-End Connection?

There are certain times where a connection to a back-end environment is neither available
nor desired. In these environments, security becomes more of a challenge because of the
obvious inability to manage security keys, identities, and dynamic authentication
mechanisms. However, a fair level of security can be achieved. Consider the following:
Implement a Trusted Computing Base

Defining an Organizational Root of Trust
Authenticating an Endpoint identity
Environments Without Back-End Connectivity
5.13 How do I Ensure my Consumers Privacy?

Consumer privacy is a complex issue that requires an in-depth analysis of not only the
Endpoint technology, but the entire IoT product or service. Each component in the overall
system must be analysed for potential gaps in privacy. Review the following
recommendations to gain more insight on enforcing privacy:

Endpoint Communications Security
Privacy Management
Privacy and Unique Endpoint Identities
Utilize a Private APN
Unauthorized Metadata Harvesting
Non-Obvious Security Risks (Seeing Through Walls)
Lawful Interception
5.14 How do I Ensure User Safety While Enforcing Privacy and Security?
Safety is a topic that must be considered in context with the application, its purpose, the
intended environment(s) in which the application will live, the type of consumer, and the
communications technology used. There are often times it may seem that trade-offs should
be made between safety and security. This may not be true, however. Instead, the
V1.1 Page 23 of 84
architectural model may need to be shifted in order to maintain both safety and security.
Where possible, security should not be discarded in favour of safety. Both should be
enforced, where ever possible. While this is a philosophical recommendation, it is important
that safety be constantly reviewed by the engineering team. Consider the following
recommendations to start a discussion about safety in IoT:
Safety Critical Analysis

Intentional and Unintentional Denial of Service
Lawful Interception
5.15 What Issues Should I Not Expect To Resolve?

In every system there are risks that cannot be resolved due to the laws of physics, cost, or
simply a lack of technological solutions. Some of these issues are noted here:
Intentional and Unintentional Denial of Service

Defeating Shadowed Components and Untrusted Bridges
Non-Obvious Security Risks (Seeing Through Walls)
Combating Focused Ion Beams and X-Rays
Lawful Interception
V1.1 Page 24 of 84
6 Critical Recommendations
When developing a secure Endpoint, the following recommendations should always be
implemented. The following critical recommendations define a secure Endpoint architecture.
Without these recommendations, the Endpoint will have an incomplete security profile that
will be abused by an adversary.
6.1 Implement an Endpoint Trusted Computing Base

The first step in securing any embedded system is the definition of the Trusted Computing
Base (TCB). In the context of an Endpoint (or similar embedded devices), a TCB is a suite
composed of hardware, software, and protocols that ensures the integrity of the Endpoint,
performs mutual authentication with network peers, and manages communications and
application security.
The core of the TCB is the trust anchor, a secure hardware technology that stores and
processes cryptographic secrets such as Pre Shared Keys (PSK) or asymmetric keys. Trust
anchors, such as an UICC, can be used to authenticate not only peers during network
communications, but can be augmented to store data useful for Endpoint application
security.
Once the trust anchor is chosen and integrated into the Endpoint solution, libraries can be
chosen or designed that integrate the trust anchor into the overall TCB suite. The TCB will
allow the Operating System and the Endpoints primary applications to more easily manage
the overall security of not just the device, but the network.
It is important that the engineering team choose the correct trust anchor for the solution, as
each combination of trust anchor and TCB will result in different level of security. Some
combinations and trust anchor implementations will result in a false sense of security.
The most common variations of a Trusted Computing Base, in order of least secure to
most secure are:
None implemented (Plain text)

Static Pre-Shared Key (PSK)
Static Public Key
Personalized PSK
Personalized Public Key
V1.1 Page 25 of 84
Figure 3 - Security assurances provided per each type of TCB.
Consider the figure above. In this diagram, each TCB variants capabilities are given a
weight. A thumbs-down icon denotes that the TCB model cannot accommodate for the
security strategy depicted along the top row. A stop-watch icon shows that the security
strategy can be used, but will be subject to a break in security within a reasonable amount of
time. A thumbs-up icon shows that the security strategy can be implemented soundly, and
that the lifetime of the security strategy will likely be long-lived.
While a TCB can be used to secure many aspects of the overall IoT product and service, this
document focuses on five core concepts:
Executable image validation
The mutual-authentication of network peers
Separation of Duties within the IoT security architecture
Provisioning and Personalization
Isolated Environment security (or connectionless site security)
A TCB that implements executable image validation secures the Endpoint device by
cryptographically verifying each executable image to be loaded and executed by the device.
This process starts at the bootloader, which should cryptographically validate the next stage
of execution, typically an operating system kernel. The bootloader could also validate the
operating system image, or a firmware application image stored in NVRAM.
A TCB that implements mutual-authentication of network peers helps provide a root of trust
for the authentication of network components, and cryptographically authenticates itself to
network peers. This increases the likelihood that peers on the network represent the
V1.1 Page 26 of 84
identities that they claim to represent. For example, if the network peer claims to offer a
firmware-update service, the TCB would authenticate the peer as being a part of the core
IoT Service Provider network before accepting firmware updates from the peer.
A TCB that implements a separation of duties uses a hierarchy of keys to identify varying
components or services within the IoT Service Providers offerings. For example, one set of
cryptographic keys could represent a firmware update service, while a second set of
cryptographic keys could represent a push service. Since these services have a completely
disparate functionalities, they should not use the same cryptographic keys and identities for
communication. As such, the TCB should manage and verify each identity to separate one
service or function from another. This reduces the ability for an adversary to compromise the
entire IoT service infrastructure if one of the cryptographic keys is compromised. In other
words, if an Attacker compromises the key for the push service, they will not also have the
ability to impersonate the firmware update service.
A TCB that implements personalization and provisioning ensures that the Endpoint has an
identity that is cryptographically unique from every other Endpoint of its type. It also ensures
that all communications identities are safeguarded to reduce the potential for privacy leaks
or tracking.
A TCB that implements isolated environment security enforces policies and procedures that
validate the authenticity of peers and the confidentiality and integrity of data even if there is
no back-end service to help in the process. In other words, if communication to back-end
services are cut off for an extended period of time, the localized IoT ecosystem will still be
able to function with a high degree of security. Though the integrity of isolated environments
degrades over time, a well designed TCB that implements isolated environment security can
strengthen the resilience of the network and lengthen the amount of time that the
environment can be considered secure.
In this context, personalized is indicative of a unique set of keys that are associated with a
specific trust anchor. The personalization process includes the generation and installation of
the unique keys, the association of the keys with the unique chip, and the secure
dissemination of this information and the relevant metadata to the appropriate authorities.
This ensures that each chip has a unique cryptographic identity. Static, in this context, refers
to the same set of keys used for every Endpoint.
While TCBs can be used to solve almost any security concern an embedded system may
have, there are several core problems that a TCB must be able to solve
Endpoint application image validation

Network authentication and/or peer authentication
A separation of duties
Provisioning and personalization
Isolated environment (connectionless site) provisioning and communication
Randomization
V1.1 Page 27 of 84
While it is obvious that choosing to not implement a TCB results in a lack of security, there
are subtleties to the other common TCB implementations that should be addressed. If these
subtleties are not addressed, they may result in substantial gaps in security.
6.1.1 Trust Anchor Key Models
6.1.1.1 Static Keys

A static key implementation, whether it is PSK or asymmetric keys, is defined as a solution
where every Endpoint utilizes the same cryptographic secret to solve a given problem. While
different keys may be used to solve different core problems, the key is still the same set for
each Endpoint.
This model seems secure in that each problem solved by the TCB can be done effectively.
However, the lifespan of the overall solution can range from long to extremely short.
Depending on the security of the trust anchor and the cryptographic algorithm and key size
chosen, adversaries may be able to break the solution almost immediately.
The problem really arises in that a single compromise of the key exposes every Endpoint
system to compromise. This devalues the TCB implementation and negates the time and
money used to implement the solution in the Endpoint and overall IoT architecture. Thus,
this model is a dangerous TCB to implement as it is, effectively, a time bomb.
6.1.1.2 Personalized Keys

Regardless of whether a PSK or asymmetric solution is implemented, personalization is
imperative for a TCB to work effectively. Personalization negates the ability for an adversary
to use a compromised trust anchor to subvert the security of the entire IoT ecosystem. If an
adversary is only able to compromise a single Endpoint at a time, and they require physical
access to do so, it will be extremely slow, expensive, and complex to implement a wide
compromise of the IoT technology. This is a significant win for the business.
Because of the standards in cellular communications that have evolved over the past several
decades, Network Operators have perfected the PSK model for personalization of trust
anchors, such as UICC. As a result, UICC can sometimes be provisioned to serve as an
application trust anchor by the IoT Endpoint, helping to form a cost-effective security solution
for IoT applications. In the near future, when eUICC are available, this capability can be
enabled even on eUICC already deployed in the field.
Today, personalized key technology is the most effective security solution for a trust anchor.
TCBs implemented in IoT today should be based on a personalized TCB solution. IoT
Service Providers should have a discussion with their Network Operator to determine if the
UICC or SIM can be implemented as an application layer trust anchor.
6.1.2 TCB Protocols and Technologies

Along with a trust anchor, the TCB must incorporate protocols, policies, and software
libraries to provide security to the overall IoT product or service. One advantage to the
utilization of cellular-backed standard trust anchors is the ability to drop in provisioning and
personalization software that already exists for Network Operators. Technologies, protocols,
and suites such as the following will assist with the TCBs ability to help authenticate the
Endpoint to the network:
V1.1 Page 28 of 84
oneM2M SM UICC application as specified in oneM2M TS-0003
Generic Bootstrapping Architecture (GBA) 3GPP TS 33.220 (See Annex A)
Use of these technologies will help speed up the implementation of provisioning and
personalization as the libraries and protocols have been vetted by experienced engineers
and security analysts for many years. Yet, these protocols may not fully enable the TCB to
validate the Endpoints application, or ensure that the Endpoint can properly authenticate
messages, or authorize actions. The TCB must incorporate other protocols to accomplish
these tasks, such as firmware validation, over-the-air update message validation, and more.
In the near future, technology such as eUICC will augment the capabilities from the
perspective of the application, and proactive UICC enable dual-use technology that can help
bootstrap the Endpoint itself, while managing Network security. This is an important
augmentation as Network Operators can remotely and securely manage the eUICC device
on behalf of the IoT service provider. In addition, the Confidential Card Content Management
functionality specified in GlobalPlatform Card Specification [15] enables several actors in the
IoT service ecosystems to manage their own application independently of each other, if
allowed by the network operator.
6.1.3 Risk
Choosing to not implement a TCB is a critical point of failure for the entire IoT architecture.
Without a well defined TCB, the interplay between the trust anchor and core application will
be loosely defined, and may have gaps that can be subverted by adversaries. The TCB
ensures that communications between the trust anchor, core application, and network peers
are secure, reliable, and up-to-date. Without a TCB, there is no central component to
manage the security lifecycle of the Endpoint.
6.2 Utilize a Trust Anchor

In order for an Endpoint to participate in an ecosystem, it must be able to verify the integrity
of its own platform, and must be able to authenticate the identity of its peers. To do this,
Endpoints require a trust anchor incorporated into a Trusted Computing Base.
A trust anchor is a secure hardware element, either a separate physical chip, or a secure
core inside a CPU, that is capable of securely storing and processing cryptographic secrets.
A UICC or eUICC device is an example of a secure technology that can be used as a trust
element to store authentication secrets.
Using a trust element effectively involves storing, verifying, updating, and processing data.
The data can be either secret or public information that must be cryptographically verified. In
either case, the trust anchor must be able to securely determine whether messages and
identities can be authenticated, and must be able to securely tell the TCB the result of all
authentication or cryptographic operations. This allows the Application, and the TCB, to
make valuable decisions that will affect the security of the overall Endpoint. For instance, a
trust anchor can help an Endpoint determine whether a network peer is impersonating a
critical resource, such as a patch deployment server. If the trust anchor cannot validate a
network peer, the TCB and Application on the Endpoint should choose not to interact with
such a peer, and should alert the user, where possible, of the fraudulent network resource.
V1.1 Page 29 of 84
Thanks to the decrease in the cost of components and a sharp increase in demand, trust
anchors are becoming more available than ever before. This not only includes the actual
trust anchor technology, but libraries and interfaces approved for use with the technology.
This allows the engineering team to spin up a trust anchor solution in very little time, and will
help to ensure that the longevity of the technology is not weakened by custom software or
poorly implemented standards. Where possible, standards should be used to diminish the
potential for gaps in security.
Another challenge in implementing a trust anchor in lightweight Endpoints is the size of the
component. If an external trust anchor is utilized, it will be necessary to maintain a minimal
component profile. Achieving this profile is difficult when the form factor incorporates
technology such as a UICC. However, the ETSI TS 102 671 standard solves this problem by
introducing a very small form factor of approximately 6 millimetres by 5 millimetres in size.
These MFF1 and MFF2 augmentations to the UICC smart card form factor enabling full
access to technologies supported by the UICC while ensuring the physical requirements are
minimal. Extra security is added by utilizing a field-provisioned form-factor that is soldered
onto the device, making it more difficult for adversaries to transfer a devices identity to
another device.
Expenses incurred in the development and deployment of a trust anchor can include:
The cost of the base technology, either embedded within the CPU or a separate chip
The cost of integrating the technology into the circuit, where required
The cost of engineering or integrating the driver into the OS and TCB
The cost of engineering the Application to use the trust anchor
Maintaining the trust anchor, where required
o Maintaining security keys, revoking keys, and decommissioning identities
o Maintaining the infrastructure required to secure and manage the keys and
metadata
Monitoring the trust anchor identity on the Service side
o Implementing device blacklisting, where required
Integrating carrier services, where available, to monitor and manage trust anchors
such as UICC
6.2.1 Risk
The risks of not utilizing a trust anchor are many, but all stem from the same base issue: the
ability for an adversary to steal keys relevant to the entire IoT ecosystem. The result of this is
that an adversary can:
Clone Endpoint identities

Impersonate IoT services
Deploy unauthorized patches or updates
V1.1 Page 30 of 84
Make unauthorized changes to the Endpoint software
These gaps in security can result in costly issues to the business over time, and can allow
not only adversaries, but competitors, to abuse the infrastructure toward their benefit.
6.3 Use a Tamper Resistant Trust Anchor

Some Trust Anchors have extra physical security to guard against certain classes of attacks,
such as FIBs, side-channel analysis, and glitching. While some attacks, such as the
utilization of a FIB, are almost impossible to guard against from a cost perspective, the trust
anchor manufacturing can use modern technologies to make attacks more costly. The more
costly an attack is, the less likely it will be used against random Endpoint devices. Instead,
attacks will be focused on targets where the expense is worth the reward.
In the near future, some trust anchor manufacturers are planning to roll out variations of their
technology that are Federal Information Processing Standards (FIPS) [10], EMVCo [11] and
Common Criteria approved. Engineers developing new technology should determine
whether their current designs will support a move to compliant modules in the near future.
For more information, review the latest version of each standard to evaluate what level of
capability is offered by your manufacturer. Note that some levels of security are purposefully
close to impossible for consumer-based devices due to the cost and complexity of
implementations.
6.3.1 Risk
The risk of not using a tamper resistant trust anchor is extremely high. For example, if a trust
anchor is simply cryptographic keys embedded in NVRAM, any Attacker with the tools and
skill to extract those keys can potentially subvert the entire infrastructure. However, if the
secrets are stored in a tamper resistant trust anchor, the expense to extract the secrets is
high, which will make it far less likely that the secrets will be extracted, devaluing the trust
anchor as a potential attack target.
It is notable that if the trust anchor implementation is weak, the extraction of secrets resulting
in a compromise can be sufficiently high. Any compromise will invalidate the expense
incurred during engineering, architecture, production, and fulfilment. This may result in a
significant financial loss. Therefore, ensuring that the organization has architected the
correct implementation is imperative.
6.4 Utilise an API for the TCB

Once a root of trust has been established within the TCB, a protocol must be used that
incorporates the TCBs capabilities and the root of trust effectively. The API should ensure
that:
All signature verification is performed by the TCB

No private keys are exposed from the TCB
Key exchange can be performed by the TCB on behalf of the application
Decryption can be performed by the TCB
Encryption can be performed on the TCB
Message signing can be performed on the TCB
V1.1 Page 31 of 84
Secure message padding can be performed on the TCB

Confidentiality and Integrity between the TCB and the application
This set of capabilities will help guarantee that the TCB never exposes critical security
assets to an insecure application or hardware environment. This can be accomplished by
using an existing specification that applies these requirements in a uniformed fashion.
Consider evaluating:
SIM Alliance Open Mobile API [12]
GlobalPlatform Secure Element Access Control [13]
GlobalPlatform Trusted Execution Environment (TEE) API Specification [14]
Trusted Computing Group (TCG)
Many trust anchors will come with software libraries that can be implemented as a TCB.
These libraries will have APIs that the engineers can use to interact with the TCB. Libraries
provided by the trust anchor are preferred, where available, as they have likely been vetted
by experts in the field of trust anchor development. However, the engineering team should
evaluate the list of requirements set forth in this recommendation, and should ensure that
the library adequately accounts for these concerns.
Furthermore, TCBs should only be accessible from privileged applications running on the
Endpoint. A TCB interface should never be accessible from an unprivileged or untrusted
(third party) application running on the Endpoint. All access must be proxied through a
trusted service that evaluates requests and optionally alerts the user when suspicious or
privacy-centric requests are being made by untrusted applications.
The challenge in implementing this protocol is guaranteeing that all messages cannot be
tampered with between the point of origin for the data and the TCB, and vice-versa. It is
most effective if a segment of EEPROM, callable from the application, can perform these
functions on behalf of the application. By isolating the brunt of the API code to the internal
EEPROM, and using internal RAM to process the messages, less critical data will be
exposed to external busses.
6.4.1 Risk
If an Application Protocol Interface isnt well defined, using a TCB may have unintended
results or side effects. By defining the protocol ahead of time and vetting it for logic and
security issues, the engineering team can more quickly and effectively identify flaws that
may result in security issues later. Thus, the definition of the protocol should incorporate the
evaluation of existing APIs that incorporate the needs of the IoT Service Provider. If an
existing and well-established technology can be identified, this will always be favourable
over a custom solution.
6.5 Defining an Organizational Root of Trust

An organizational root of trust is a set of cryptographic policies and procedures that govern
how identities, applications, and communications can and should be cryptographically
secured. Strong cryptography should be used, either in the form of unique symmetric keys,
V1.1 Page 32 of 84
certificates, or public keys. This depends on the model available for use in the TCB, the
capabilities of the trust anchor, and what makes sense for the engineering team.
A root private key, either symmetric or asymmetric, should be used to digitally sign other
keys used in the hierarchy. For example, if our example organization, Example IoT Company
LLC, wants to create an organizational root of trust, they would generate a root key on a
trusted machine. This key will represent the organizational root. They would then generate
new keys representing each sub- organization that should have independent security
hierarchies. Examples may be:
Code signing key

Server communications key
Peer-to-peer communications key
Endpoint identity key
Master revocation key
Each of these keys should be signed by the organizational root key. All of these keys, their
corresponding signature, and the root key should be stored in the trust anchor used by the
TCB. Then, whenever the application linked to a particular key is used, the application can
use the specific keys to validate messages sent over communications channels.
This model helps to ensure that all messages are secured through the cryptographic
hierarchy. By separating duties among specific key types, compromised keys can be
revoked through the same communications process.
Some existing protocols that assist in deploying this method are:
Transport Layer Security (TLS); The latest valid specification

Secure Shell (SSH2)
Online Certificate Status Protocol (OCSP) IETF RFC 2560
Generic Bootstrapping Architecture (GBA) (See Annex A) 3GPP TS 33.220
Difficulty arises when services that need the cryptographic keys must be deployed. Instead
of placing a security-critical asset, such as the Server communications key, on a web server
accessible to the Internet, a separate certificate or key pair should be generated specifically
for that server tier. Then, this certificate may be signed by the Server communications key.
This way, any Endpoint can verify that the service has been authenticated by the root of
trust, but the critical organizational key will not be exposed to adversaries.
If a key is ever compromised, it can be revoked from use by using the Revocation master
key to authenticate revocation.
It goes without saying that all core keys in the organizational root of trust are critical to the
security of the infrastructure. These keys must be heavily guarded, and only used by trusted
internal members of the core team. Utilizing an approved Hardware Security Module (HSM)
to store, access, and use the keys is highly recommended.
While an HSM can often be a significant expense at the start of a technologys deployment,
the long-term financial effects are highly positive. Rather than incur a significant expense
V1.1 Page 33 of 84
later in forensic analysis and engineering to diagnose and combat a particular risk that could
have been solved by a TCB and an HSM, a relatively small up-front expense is incurred.
6.5.1 Risk
The risk of not using an organizational root of trust is that any compromise to a single key
can result in compromise of the entire ecosystem. By separating the organization into a
hierarchy, and deploying separate keys for the hierarchy, keys can be cycled at regular
intervals and according to the priority of the application or sub-organization the key relates
to. This creates a separation of duties between facets of the organization, and diminishes
the ability for a compromised key to subvert the security of the entire infrastructure.
6.6 Personalize Each Endpoint Device Prior to Fulfilment

Endpoint devices must be enabled with cryptographically unique identities to ensure that
adversaries, competitors, and hobbyists cant impersonate other users or devices in
production environments. To accomplish this adequately, the personalization process must
be performed at fabrication. This can be done either through the manufacturer of the
particular TCB solution, or during the Printed Circuit Board Assembly (PCB/A) process.
To solve the personalization process, perform the following:
Generate a unique cryptographic key

Sign the key using the organizational Endpoint Signing Key (or a derivative of)
Store the key in the TCBs trust anchor
Generate (or use) a unique internal identifier for that specific Endpoint
Store the unique identifier in the TCBs trust anchor
Save the unique identifier, the key, and the signature in the IoT Service back-end
authentication system
Note that personalization of the Endpoint platform is separate from personalization of the
network identity. Utilizing a UICC for network authentication is beneficial for many reasons,
and where possible, the UICC could be used as a trust anchor. However, if the network trust
anchor can only be used for authentication of the network, personalization of the application
trust anchor must be performed separately. Cryptographic uniqueness of the application
trust anchor is required to ensure that the application platform is verified prior to execution of
the Endpoint application.
Using the proper agreement with a network operator or other issuing party, UICCs can
sometimes be provisioned before delivery to serve as an application-centric trust anchor. In
the near future, Endpoint developers should evaluate whether eUICC technology is suitable
for use in IoT products and services. These technologies will allow in-the-field provisioning of
cryptographic secrets in a fashion similar to an application-centric trust anchor. Since the
mobile industry is a leader in the personalization and provisioning process, there may be a
significant advantage to using an eUICC as a trust anchor.
Furthermore, these technologies will incorporate remote provisioning capabilities and Secure
Channel for secure communication between the application and the eUICC trust anchor.
These capabilities will provide in-field personalization, which will reduce the overall cost of
Personalization and Provisioning for each individual Endpoint.
V1.1 Page 34 of 84
A short tutorial on use of UICC cards in an IoT service ecosystem is contained in Annex B.
The challenge comes with managing the Endpoint identities and the signing process. Each
identity must be catalogued, along with unique identifiers matching the identity, in a system
that cannot be tampered with. While the process is usually performed at the PCB/A facility, a
connection from that facility to the business must be set up to securely traffic the identity
data.
Rolling out this solution may be straight-forward with some facilities that are more familiar
with cryptographic personalization. Other fabrication facilities may not have a process in
place to accomplish this. The mobile industry has been able to succeed in this fashion due to
their ability to control the fabrication and fulfilment of embedded technologies such as UICC.
While the mobile industry has been a leader in this process for some time, the IoT
application Endpoint personalization and provisioning process is still in its infancy.
Be prepared to determine whether the identity of the Endpoint should (or could) be managed
by a gateway or uplink. Evaluating the architecture of the IoT product or service will help
determine whether this attribute of identity management will affect the personalization
process. While trust may be distributed to gateways, the organization should determine
whether trust can be adequately delegated without diminishing the overall security of the
communications and authentication system.
Expenses involved in personalization typically include, but are not limited to:
Implementation of the personalization process at the chip manufacturer
Coordination or delivery of the unique personalized values at both the manufacturer

and the IoT Service Provider
Implementation and management of the personalized identities
6.6.1 Risk
If the organization chooses not to implement personalization of the Endpoint device, they
risk being unable to differentiate one Endpoint from another. If all keys are conformed across
Endpoint systems, it doesnt matter if serial numbers are unique. The reason for this is that if
keys are extracted from any single Endpoint, the adversary would be capable of
impersonating any Endpoint.
Personalization combats this by forcing the adversary to extract the cryptographic secrets
from each Endpoint they want to clone or impersonate. Because the expense of this process
can be very high, personalization using a trust anchor is the single strongest method for
combatting cloning and impersonation.
6.7 Minimum Viable execution Platform (Application Roll-Back)

A Minimal Viable execution Platform (MVeP) is the minimum amount of work that must be
performed in order to create a reliable execution environment to communicate with the trust
anchor. Typically, this means:
V1.1 Page 35 of 84
Configuring the internal clock or oscillator

Configuring core peripherals (memory, storage)
Enabling various hardware bridges or peripheral devices
Authenticating the next chunk of code to be executed by the CPU
Executing the next stage of code
Managing application image roll-back
Once this MVeP has been defined, the minimal bootloader can use the trust anchor to verify
a more robust bootloader, or can execute the rest of the bootloader after verifying external
applications. This allows a consistent environment to be defined with minimal effort that
authenticates subsequent chains of code that will define the applications platform.
Another benefit is that with using the MVeP model, even processors with a minimal amount
of internal NVRAM or EEPROM can bootstrap a trusted architecture using an internal or
external trust anchor.
Lastly, an MVeP is important for rolling back to stable versions of a particular platform. If an
MVeP can be defined that has the minimal functionality required to verify the integrity of
application firmware images and configure the execution environment, its functionality can
be separated from the core application functionality. Thus, if a firmware update fails for any
reason, the MVeP can still be used to reconnect to the back-end network and download
another firmware image (either the same image, or an older image). This also enables
Endpoints with damaged NVRAM chips to still communicate with the back-end services and
submit diagnostic information.
6.7.1 Risk
While it may seem benign, defining a MVeP ensures that the architecture of the overall
Endpoint cryptographically verifies each step in the boot process. This step is critical in
ensuring that an Endpoint can authenticate itself to the network, and its peers. If the MVeP is
poorly architected, it can result in security gaps in the boot process that may be exploitable
by adversaries, invalidating the security architecture.
6.8 Uniquely Provision Each Endpoint

While personalization guarantees that each device is unique once it is manufactured,
provisioning ensures that a unique device is activated, updated, and associated with a
particular customer identity. The provisioning process helps separate devices that have been
manufactured from devices that have been purchased and/or deployed in an IoT
environment. This helps the IoT Service Provider:
Distinguish between active and deactivated devices
Associate Endpoints with networks or other resources linked with a particular

customer
Customize an Endpoint according to the customers needs
More easily determine whether a particular customer or Endpoint has been

compromised
V1.1 Page 36 of 84
The provisioning process does not happen during manufacturing, but relies on the
personalization process deployed in manufacturing. Provisioning typically occurs in the field,
based on the customer that initializes the activation process. Yet, for the process to be
secure, provisioning relies on the unique security tokens set during the personalization
process to ensure that the unique Endpoint is tied to a unique customer. This way, an
adversary cannot arbitrarily register (or unregister) Endpoint devices simply by guessing
Endpoint details. They would, instead, require each unique cryptographic token generated
and set during the personalization process, which is computationally infeasible.
In this fashion, the IoT Service Provider can mathematically guarantee that it is improbable
that adversaries can arbitrarily spoof or register Endpoint devices at will. This leads to a
more secure and stable IoT environment, where the relationship between customers and
devices can be more trustworthy.
6.8.1 Risk
Not implementing the provisioning process can result in a desynchronization between the
organization and its Endpoint nodes. It will be more difficult for the organization to track
Endpoints and established which devices have been enabled for use in the ecosystem or
decommissioned. Furthermore, it may be difficult to establish which devices are associated
with particular customers, which will increase the difficulty of tracking down a problematic or
potentially compromised device in the field.
6.9 Endpoint Password Management

Devices that incorporate user interfaces must be capable of managing passwords
effectively. This requires several things
Brute-force attack mitigation

Disabling the use of default or hardcoded passwords
Password best-practice enforcement
Disallowing display of user credentials on login interfaces
Enforcing thresholds and incremental delays for invalid password attempts
Users will need to be secured from the simplest attack possible, another user attempting to
guess their password. This can be alleviated by simply negating the potential for a brute-
force attack. This can be done by increasing the time limit between password attempts. With
each failed login attempt, there should be an increased delay before the next password is
allowed to be entered. A ceiling should be implemented such that no more than N attempts
can be tried at once. Otherwise, a reasonable lockout period should be enforced. The user
should be alerted to the brute-force attempt once the real credentials are entered.
Hardcoded or default passwords should never be used in IoT systems. There should never
be an administrative back door password to enter a system. There should never be a
privileged account with default credentials. This is essential to guard user devices against
unauthorized intrusion by users trolling randomly on the Internet for weak security.
Passwords must meet minimum quality requirements representative of the current

information security best practice. This ensures that brute-forcing a password will be difficult,
V1.1 Page 37 of 84
and helps the user guard against theft. Consider reviewing the OWASP or SANS guidelines
for password security to ensure the application complies to recent best practices.
Passwords must never be displayed on a users screen. Always hide the password with the
asterisk character, or another benign glyph.
In addition, all interfaces that accept passwords must utilize brute-force mitigation
technology. It is also important that the technology that validates the password must do the
enforcing. For example, JavaScript embedded in a web page rendered on a web browser
should not implement brute-force mitigation. Any web savvy Attacker can bypass these
controls by interacting with the back-end authentication server over the Internet. The
mitigation technology must be implemented on the server side in this model. In mobile
applications, where a local pin or password is embedded in the applications secure storage
region, the mobile device must mitigate brute-force attacks in this interface.
Furthermore, after each invalid password is attempted, the mitigating system should
increase the delay that is required between allowed attempts. There must also be a
maximum threshold for invalid password attempts. After this threshold is reached, the user
should be locked out pending either two-factor authentication or another more invasive
model. Difficulty
This process is extremely simple to implement, and takes very little effort on the part of the
engineering team.
6.9.1 Risk
The risk of not implementing this recommendation is:
The ability for stolen devices to be subverted through brute-force password guessing
Drive by Internet attacks can subvert the security of IoT systems by simply using
hardcoded passwords
Users can be compromised through shoulder surfing if the user interface displays
the actual password being input into the system
6.10 Use a Proven Random Number Generator

Determine whether your TCB is capable of truly random number generation. This is
important as without it, the cryptographic verification process can be impaired, making
encrypted data more guessable and weakening data integrity.
This is also extremely important for unique cryptographic key generation. Given a set of
environmental conditions, an adversary must not be able to influence the environment to
cause a TCB to generate predictable numbers during key generation, signing, or
cryptographic message padding.
This process is as simple as identifying whether the TCB is capable of FIPS [10], EMVCo
[11] or Common Criteria approved random number generation.
V1.1 Page 38 of 84
6.10.1 Risk
Utilizing cryptography without a strong random number generator is dangerous for many
reasons. While the reasons are too many to list here, there are some key weaknesses that
should be noted:
Cryptographic key generation may be compromised, causing weak or predictable

keys to be generated
One Time Passwords/Pads or keys may be weak or predictable
Message padding used to negate the potential for message replay may be
compromised
These issues can result in significant failures in the overall integrity of the cryptographic
security of the entire IoT ecosystem. This risk does not only affect the Endpoint device, it
affects the entire network.
6.11 Cryptographically Sign Application Images

All applications stored outside of a CPUs core EEPROM must be cryptographically
authenticated. To do this, simply follow the procedure:
Identify the metadata representing the version of the application image

Generate a cryptographic hash of the application image, including the metadata
Validate that the application metadata matches the internal metadata
Validate that the hash value matches the value internal to the trust anchor
Cryptographically validate the signature with the Application Signing Key
Cryptographically validate that the Application Signing Key was signed by the
Organizational Root
This process is ordered to perform the most volatile activities first, and the operations least
likely to fail last. This way, the least amount of work is performed in order to observe the
most likely risks.
This process is exceptionally easy to implement, especially when the TCB is capable of
performing the brunt of the processing on the applications behalf. The real challenge is
more subtle: it is what application is performing the operation.
An application that hasnt been cryptographically verified cannot perform the operation, as it
has no way of knowing whether its own code has been subverted by an adversary. Altering
code in NVRAM is a common way for Attackers to manipulate embedded systems, if the
embedded system doesnt verify the application.
An internal EEPROM application must, instead, perform this procedure first, on any
application image in external persistent storage. Then, that application may either perform
the operation itself, or may request an application encoded into internal EEPROM to perform
these types of tests on its behalf.
6.11.1 Risk
If the application image stored in Endpoint firmware (NVRAM) is not cryptographically
signed, the system will not be able to differentiate between authorized code and code
V1.1 Page 39 of 84
injected by an adversary. This could allow not only an adversary to abuse executable code
to manipulate a physically compromised Endpoint, but could allow a rival business to install
their own software on an Endpoint.
6.12 Remote Endpoint Administration

While not all Endpoints require remote administration, the ones that do must be architected
in a way that ensures that third parties cannot abuse administrative credentials to
compromise some (or all) of the Endpoints in the field. The appropriate solution will depend
on the capabilities of the Endpoint. However, the following guidelines should be used
Do not place private cryptographic components in insecure storage on Endpoints,

such as SSH private keys, TLS private keys, or passwords
Where possible, generate administrative tokens (cryptographic keys or passwords)

per each Endpoint
Where passwords are used, enforce the use of passwords that conform to best
practices regarding password complexity and length
Where possible, enforce two-factor authentication for administrators
Ensure that the end-user is made aware when an administrator remotely accesses
the Endpoint
Consider restricting administrative access to a Virtual Private Network (VPN)
Do not embed remote administrative capabilities into a publicly accessible application

or API, use a separate and distinct communications channel
Enforce confidentiality and integrity on the administrative communications channel
Diminish the potential for replay of administrative commands by ensuring the

communications protocol has adequate entropy by using an industry standard
communications protocol
6.12.1 Risk
Failure to define, implement, and enforce a policy on remote administration may result in the
remote compromise of Endpoints. If there isnt a rigid security model for super-user access
to the Endpoint devices, adversaries may be able to reverse engineer the technology, or
extract security keys from the Endpoints that will result in access to every Endpoint in the
ecosystem. Administrative access is often one of the first technologies abused by
adversaries in embedded systems, as they are often misconfigured or technologically weak.
6.13 Logging and Diagnostics

In order to assess problems with Endpoint devices, the IoT Service Provider should
constantly evaluate the behaviour of the Endpoint and determine whether the Endpoint is
functioning within the set of approved behaviours. To accomplish this, three strategies
should be used
Anomaly detection
V1.1 Page 40 of 84
Endpoint logging
Endpoint diagnostics
An Endpoint should log its own behaviour and intermittently upload this log to back-end
services for processing. This log should be composed of normal activity such as kernel logs,
application logs, and other metadata.
Diagnostic information should also be observed at regular intervals and delivered to the
back-end service either with or separate from normal logs. Diagnostic messages should
include as much environmental data about the Endpoint as possible, including temperature,
battery life, memory usage, execution time, process lists (where applicable), and more. This
information will help to identify when and what service(s) is related to a problematic or
anomalous event.
Anomaly detection in the network should assist in catching a problem that cant be revealed
through log or diagnostic analysis. It also will help to classify issues that can be observed in
the logs or diagnostics, or attribute the issues to a specific component that may be reacting
poorly in the physical world. For example, a cellular module that keeps reconnecting to the
network, or a sensor that generates bad data.
Together, this information will not only help identify whether a flaw in the technology is
observed in the field. It will also help to identify whether anomalous behaviour is indicative of
a security event.
6.13.1 Risk
Failing to implement logging and diagnostics may cause the organization to miss critical
information. This information may not simply impact the security of the ecosystem, but may
help diagnose critical product engineering flaws.
6.14 Enforce Memory Protection

Embedded systems are often designed with microcontrollers that are not capable of robust
technology such as Memory Management Units (MMU) and Memory Protection Units
(MPU). However, these technologies must be used in any platform that wants to:
Run unprivileged applications
Run untrusted (third-party) apps or applications
Run an emulator or virtual machine in an unprivileged process
Any environment that requires an unprivileged application to run must be able to secure itself
from rogue or compromised applications. This ensures that these rogue or compromised
applications cannot access areas of memory that control privileged resources such as the
TCB, the trust anchor driver, or hardware peripheral registers.
The challenge in this area is often migrating from an eight-bit microcontroller platform to a
more robust platform, such as a 32bit microcontroller or a full processor architecture.
However, there are many operating systems available either free or with a nominal license
V1.1 Page 41 of 84
fee for embedded systems that correctly implement memory protection with either an MPU
or MMU.
6.14.1 Risk
If these technologies are not used, rogue or compromised applications will not be restricted
from altering core resources such as drivers, peripheral registers, or even privileged services
such as the kernel and other applications. A lack of memory protection allows any
application to have full access to the full range of memory present on the microcontroller or
processor. Unprivileged applications must be restricted from abusing these resources.
6.15 Bootloading Outside of Internal EEPROM

Most bootloader code is embedded within Electrically Erasable Read-Only Memory
(EEPROM), internal to the CPU. This is not always the case, however. Determine whether
your CPU loads its Bootloader from an external source. If the CPU has no EEPROM
allowing it to verify the Bootloader code, it may be manipulated by a local Attacker to
configure the CPU in a fashion beneficial to the Attacker.
Depending on the level of protection provided to the chip or region of memory hosting the
Bootloader, an adversary may be able to use a local bus (such as Serial Peripheral Interface
(SPI)) or a remote API (such as Firmware Over-the-Air) to manipulate the embedded code.
This will result in an adversary being able to subvert the computing platform by placing
custom code at the most trusted point of execution, the first stage of executable code.
Another attack could be an adversary simply swapping one Bootloader chip for their own
chip containing custom instructions by desoldering then soldering the new chip. Without a
way to verify the integrity of the external code, the user will be unable to distinguish between
approved and unapproved software.
In order to customize a boot loader, an Attacker would either need to develop, or outsource,
bootloader development. Depending on available resources, and the target processor, the
difficulty of this action can range wildly from extremely easy to extremely hard.
Consider using a CPU or MCU/MPU with an internal EEPROM or lock-capable NVRAM to

store the bootloader. This will help to ensure that the platform can at least verify the first
executable loaded and executed by the architecture, resulting in a more trustworthy device.
6.15.1 Risk
Not evaluating the chain of trust and enforcing a verification of integrity for the initial code
loaded by the CPU can result in a full system compromise. This step is critical toward
securing the IoT Endpoint device and, thus, the ecosystem.
6.16 Locking Critical Sections of Memory

Critical applications stored in executable regions of memory, such as first-stage bootloaders
or Trusted Computing Bases, should be stored read-only. This ensures that the device can
be booted into a valid configuration without interjection from an adversary. Without this
assurance, executable code loaded after the first stage of execution will not be able to trust
that it was booted into a valid configuration or state.
V1.1 Page 42 of 84
While it is true that adversaries can still subvert the system by replacing these critical
sections of memory with their own code, it requires them to build their own custom version of
the software, which may be a complex and challenging process. This vastly increases the
overall cost of the attack, and the skill required to succeed. Additionally, if personalization
and provisioning are used, these steps will force the Attacker to recreate the process for
every Endpoint, customizing their solution to the unique cryptographic characteristics of the
local system. This makes the overall attack exceptionally costly, and decreases the
feasibility.
To remediate this risk, simply identify whether the technology that stores critical sections of
memory is capable of being locked. Alternatively, start with a lockable EEPROM technology.
Ensure that if a lock is used, the lock is not set in software. Software-defined locks are
enabled only after the software has executed the respective functionality to engage the lock.
There will be a few millisecond window in which an adversary can abuse the unlocked state
toward their gain. Thus, hardware locks, such as fuses or lock bits, should always be
employed where possible.
6.16.1 Risk
Without a lock or read-only state, critical sections of memory can be easily altered by an
adversary. This may give them enough privilege to compromise the entire Endpoint platform
without further action, subverting all subsequent security controls used in the system.
6.17 Insecure Bootloaders

The job of a bootloader is to not only configure the CPU for execution of a primary
application, but to load and transfer executive control to the application. To achieve this, the
bootloader typically finds and loads the main application into main CPU memory. The
problem arises when default bootloaders are used on certain types of systems.
Many bootloaders used by microcontroller vendors, for example, allow external firmware to
be loaded into CPU memory for execution, or allow firmware updates over serial interfaces.
Other bootloaders may prompt a user for locations that contain application images, allowing
a user to execute any application they choose.
While this functionality is expected in an environment such as a desktop, laptop, or even

server, this is unacceptable in embedded systems. This is because if a bootloader loads and
executes an unverified and untrusted application, there is no guarantee as to the reliability or
security of the executed application, leaving the state of the embedded device in question.
Therefore, to remediate this issue:
The bootloader must be capable of cryptographically verifying the application image

to be executed
The default/standard bootloader should not be used if it allows alternative images or
firmware flashing
The bootloader must not allow application images loaded from arbitrary storage
locations
The first-stage bootloader executable image should be locked in EEPROM and
should only be updated through a secure process
V1.1 Page 43 of 84
Furthermore, the design of a bootloader should be subject to scrutiny by a third-party

security analyst. Compromising a bootloader through manipulation of bugs in the software
can lead to execution of custom code, or a bypassing of integrity verification checks. This
may lead to jailbreaking, which may not be beneficial to the business. Ensure that all
bootloaders used in the system are thoroughly audited for software programming flaws that
could lead to security risks.
6.17.1 Risk
An insecure bootloader can be as damaging as a poorly architected bootloading process.
Securing the bootloader is a critical step toward ensuring the integrity of the IoT Endpoint.
6.18 Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) deals with the disclosure of cryptographic keys exchanged
during the setup of communications between two Endpoints. Generally, the Endpoints will
have asymmetric certificates used to authenticate their identities. Upon completion of the
authentication phase, a symmetric key is generated and mutually agreed upon by using
asymmetric encryption to protect key negotiation. Once this key is generated and agreed
upon, it will then be used to secure the rest of the session between the two entities. This is
used to lower the computational expense involved in asymmetric cryptography. Symmetric
cryptography is computationally cheaper, which means both faster and less power-intensive
in embedded or low-power technologies.
However, there is a catch. This common key agreement model presumes that the
asymmetric keys are always kept secret. This may not be the case. In the future, a
sufficiently funded entity may be capable of computing the private key for any given public
asymmetric key. If the Attacker saves every communications session between a target entity
and their peers, the entity will then be able to decrypt every communication message from
the past by generating the private key sometime in the future.
In addition, a servers cryptographic key may be compromised by anonymous third parties or

even business insiders. If this occurs, anyone that has been storing communications
messages secured by the stolen asymmetric key can now decrypt those messages.
One solution to this problem is to generate an ephemeral asymmetric key pair during the key
negotiation process. Only the public key for this ephemeral key pair is passed to each side of
the communication link, it can be used to traffic a symmetric key.
This ephemeral key should be generated with sufficient entropy and a key size large enough
to negate the potential for a computational exhaustion attack within a reasonable period of
time. This will ensure that the key negotiation process is sustainable and less likely to be
subject to attack in the future.
Furthermore, this methodology ensures that peers use their persistent asymmetric key only
for authentication, not for confidentiality and integrity. If this asymmetric key is stolen or
exposed to the public it will only affect the authentication process, not the confidentiality and
integrity of the communications channel.
V1.1 Page 44 of 84
To make this process even more resilient from attack, the asymmetric key used for
authentication must be subject to a secure revocation process that guarantees that an
Endpoint will be able to verify if a key has been compromised. The Endpoint should no
longer trust that key for authentication if it has been notified that such a compromise has
occurred.
6.18.1 Risk
Not implementing PFS can expose all network communications to an adversary if that
adversary ever gains access to a private key used to secure the communications channel. At
any time in the future, if the adversary captures the private key, all communications captured
by the adversary in the past will then be decrypted. This will lead to serious consequences.
6.19 Endpoint Communications Security

While covered in several other recommendations and risks throughout this guide, it is
important to succinctly note that Endpoint communications security is the biggest threat to
Endpoints in IoT. The ability for an adversary to manipulate the communications channel is
the simplest way for an Endpoint to become compromised.
As a result, Endpoint designers must implement communications security from the following
perspectives:
Authentication of network peers

Confidentiality of data
Integrity of messages
Although clear-text messages can be sent and received in order to interoperate with
Endpoints designed by other organizations, data communicated over any channel that
incorporates commands, user privacy data, or critical system messages must be secured.
The first step is to authenticate the peer device to ensure that it is what it claims to be. This
is especially important if the peer represents a system service.
Next, data confidentiality is required to ensure that third parties cannot read critical data
passed over a communications channel.
Finally, message integrity is required to ensure that secret messages have not been
tampered by an adversary.
These three attributes, combined together, will result in a communications model that can
survive for years with few engineering changes.
This process is made far simpler through the use of existing and well analysed security
protocols, such as, but not limited to:
The latest approved TLS standard

The latest approved DTLS standard
SSH2 for authentication and key exchange
GBA for key generation and exchange
OAuth2 for authorization
V1.1 Page 45 of 84
While the engineering team can use any suite that adheres to the aforementioned
requirements, utilizing a standard communications protocol suite will reduce the number of
errors that will be observed in the field. This is because experts in information security and
cryptography are involved in the development of standardized protocols.
6.19.1 Risk
While it should go without saying that communications security is a requirement, it is
sometimes confusing as to why it is a requirement. Communications security doesnt just
ensure that an adversary cant read data. It also ensures:
An Endpoint cannot be impersonated

A critical service cannot be impersonated
Abused messages can be detected
Changes to software or security configurations can be performed safely
Without communications security, there are no guarantees as to the quality, reliability, or

privacy of an IoT product or service.
6.20 Authenticating an Endpoint Identity

If each Endpoint carries a cryptographically unique identity, such as a unique serial number,
the device must be able to prove that it truly represents that serial number. To do this, the
TCB must cryptographically sign a message with a key known only to the TCB and to the IoT
back-end service, a complexity that can be managed with technologies such as GBA. The
message should contain the unique identity (serial number or other token) and metadata
respective to the Endpoint.
The message to be signed by the TCB must also contain a challenge issued by the back-
end system. This negates the ability for an adversary to replay an authentication message
already submitted from the TCB to the back-end. If sufficient entropy is contained in the
challenge, the potential for message-replay is negated.
To challenge an Endpoints identity:
Receive a request from the Endpoint which contains the unique identity token
Generate a unique challenge and send it to the Endpoint
Receive the challenge reply from the Endpoint containing the signature and the
message
Verify that the signature is correct using the shared key
Ensure that the signed message contains the correct identity token and any other
relevant metadata
Acknowledge the verified signature
To process a challenge:
Connect to the back-end system

Receive the back-end systems cryptographic identity
V1.1 Page 46 of 84
Cryptographically authenticate the identity of the back-end system using the TCB
Send a message containing the Endpoint identity and other metadata to the back-
end
Receive a challenge from the back-end
Generate a message containing the unique identity token, metadata, and the
challenge
Sign the message
Send the message and its signature to the back-end
Verify that the back-end system approved the signed message
6.20.1 Risk
The risk of not implementing this recommendation is that Endpoints will be clonable or
vulnerable to impersonation attacks. This can open up the organizations infrastructure to
attacks from both competitors and adversaries. Competitors can use a lack of Endpoint
identity authentication to build a competing platform from the same Bill of Materials, but at a
lower cost.
Alternatively, a competitor can use the lack of authentication to sell hardware that
piggybacks off of the organizations infrastructure. These issues can result in a loss of
revenue for the business, and an increased operational expense as the competitor can
benefit from the use of the businesss network infrastructure, even though they are not
paying to use it. Since network bandwidth has a quantifiable cost, and Cloud servers, CPU
usage, disk usage, and other resources have a quantifiable cost, this kind of parasitic
business can have a serious impact on a vulnerable organization.
7 High Priority Recommendations

High priority recommendations represent the set of recommendations that should be
implemented, but only if the Endpoint architecture requires it. For example, not all Endpoint
architectures require tamper resistant product casing. These recommendations should be
evaluated to determine if the business case deems them a requirement.
7.1 Use Internal Memory for Secrets

Where possible, processors should use internal CPU memory for the processing of core
secrets and cryptographic keys not contained within a trust anchor. This will ensure that if an
adversary is monitoring, or capable of manipulating, the memory bus, they will not obtain
core secrets, but will only see the effects of the use of these secrets on a running
application.
This model will create longevity with regard to the cryptographic secrets, forcing the Attacker
away from uncovering those secrets. Instead, the Attacker will need to rely on manipulating
bits in the RAM that equate to the effects of using said secrets. This will require the Attacker
to change bits in memory every time the secrets are used internally, massively increasing
the complexity of the attack.
Not all operating systems define models for utilizing internal RAM for the processing of
secrets. Therefore, it might be required for the engineering team to implement this
themselves. While this process is not difficult, it is not trivial, either. The executable code
must ensure that its memory routines all use specific regions guaranteed to represent
V1.1 Page 47 of 84
internal processor memory. This may require extra work, depending on the operating system
and compiler toolchain used.
7.1.1 Risk
Most microprocessors and some CPUs have a small amount of internal SRAM dedicated to
code running from internal EEPROM or internal NVRAM. This SRAM is typically inaccessible
to external peripherals, unless it is purposefully exposed by using technology such as DMA.
If kept private, cryptographic secrets processed by the code have a much smaller likelihood
of being exposed to adversaries capable of intercepting RAM communications.
While it is not a high risk, cryptographic secrets should not pass over publicly accessible
busses, in order to diminish the potential for attack. Well equipped adversaries capable of
intercepting RAM communications at potentially high speeds can capture data such as
cryptographic secrets. However, it would take a skilled reverse engineer to capture
messages across RAM that could be attributed to cryptographic operations.
As a result, while this is an important recommendation, it may not be critical to ensuring

physical security. If core cryptographic keys are stored within the trust anchor, and only
session keys are processed by the application, processing the keys in external RAM is not
likely to result in an immediate compromise. However, this presumes that the cryptographic
architecture limits the exposed keys to those that are not critical to core IoT operations, such
as key rotation, session key generation, and certificate revocation.
7.2 Anomaly Detection

Modelling Endpoint behaviour is an imperative part of IoT security. This is because a
compromised Endpoint can be indistinguishable from an Endpoint behaving normally if only
successful interactions with the device are logged and analysed. For a more comprehensive
perspective of an IoT environment, the full behavioural fingerprint of a device should be
catalogued to identify anomalies that may be indicative of adversarial behaviour.
Anomalous behaviour emanating from an Endpoint may include:
Erratic reboots or device resets
Leaving or joining a communications network at erratic intervals
Connecting to abnormal service Endpoints, or connecting to service Endpoints at

inappropriate times
A significantly different network traffic fingerprint than normal
Multiple poorly-formed messages sent from the Endpoint to server Endpoints
If the normal behaviour of an Endpoint type is catalogued by the IoT Service Provider, the
organization will be able to identify behavioural patterns that should be indicative of
anomalous behaviour. By setting a baseline of behaviour, then continually monitoring for
potential outliers, the organization can more quickly diagnose both security and performance
problems in production environments.
V1.1 Page 48 of 84
Cataloguing the behavioural fingerprint may also assist the organization in more quickly
linking a faulty set of functionality to a particular feature or environmental condition. This may
lead to engineering solutions at a more rapid pace than if behavioural data isnt collected.
7.2.1 Risk
Without anomaly detection, it may take an excessively large amount of time to detect a
compromised Endpoint within the IoT ecosystem. If the Endpoints anomalous behaviour is
only visible outside of normal operations, the administrative team may have no reason to
distrust the Endpoint. However, if anomaly detection is implemented throughout the
ecosystem, malicious behaviour may be detected and thus contained far sooner.
7.3 Use Tamper Resistant Product Casing

The physical device should not only be tamper resistant at the chip level, it should also be
tamper resistant at the product level. The case used in the product should provide protection
from adversarial or curious users. This can be accomplished in several ways:
Circuits that invalidate NVRAM when a casing is opened
Sensors that blow security fuses when light is detected
Sensors that trigger an alert when a physically static devices location is moved
Epoxy covering core circuit components
Alerts raised with either internal or removable components are removed from the
device
Using these methodologies can improve the tamper resistance of a physical Endpoint.
However, it may be more cost effective to improve the design of the circuit, itself. While
these methodologies will go far to diminish the potential for compromise by amateur
hobbyists or adversaries, they will not mitigate well equipped and experienced security
analysts.
Thus, these methods improve the organisations ability to ensure that the product itself
cannot be tampered with while it is out of the possession of the consumer that owns it. In
other words, if a consumer leaves their device at home or in the field, an adversary must not
only gain physical access to compromise the device, but they must also defeat the tamper
resistant security controls as well in order to alter then replace the device. This negates the
ability for devices to be quickly compromised and replaced, which is a valuable improvement
to physical device security.
Yet, if the threat model ignores this aspect and focuses on remediating physical attack in
general, including advanced and equipped Attackers, it does not fully remediate that threat.
In that case, these tamper resistant additives will slow down an adversary, but will not stop
an adversary with time and expertise.
Thus, a balance must be met between what is cost effective, and the threat model of the
given device. An Automated Teller Machine (ATM) is a sufficient example of such a device.
Tamper resistance in the encasing is required for ATM security, to ensure that an adversary
cannot open and alter the physical encasing to, say, capture magnetic stripe data and record
V1.1 Page 49 of 84
access numbers. However, savvy adversaries have devised local-alike components,

skimmers, to be adapted on top of an existing ATM. Thus, physical tamper-proofing can only
achieve part of the desired result. Application and hardware design must go the extra step to
diminish physical attacks.
Engineers and business leaders should evaluate the threat model of a given product or
service and balance the risk of attack with the tamper resistant measures implemented in the
device. Each type of tamper resistance will incur a cost, depending on the process,
engineering, and materials involved. And yet, the effort may not result in the level of security
desired.
An example of this problem is with coating chips with epoxy. While this process is valuable,
there are two things an Attacker can easily do to bypass the use of epoxy:
Tap circuits emanating from the epoxy covered component
Remove the epoxy
While epoxy hides the chip component from view, it does not and cannot hinder the
electrons traveling across circuits that emanate from the epoxy coated chip. Thus, if critical
secrets are communicated across the hardware bus, epoxy will not stop the adversarys
ability to intercept this data.
Furthermore, the epoxy itself can simply be removed. Home grown hobbyist techniques
have surfaced in the past several years that clearly outline a practical method for removing
epoxy from a circuit using consumer ready chemicals and processes. While the process can
be caustic and potentially dangerous, the procedures outlined by skilled reverse engineers
are sound and can be implemented by anyone with a properly vented laboratory or office.
Thus, a risk assessment must be performed that clearly weighs the benefits of the tamper
resistant technology with the ease of compromise. If each device is simply to be secured
from an adversary wishing to easily manipulate or abuse a random device, tamper
resistance should be employed. If the requirement is that advanced Attackers must be
mitigated from intercepting messages across hardware busses, a more resilient security
architecture for the application and operating system should be considered over tamper
resistance.
7.3.1 Risk
As noted in the previous section, the risk of not deploying tamper resistance varies wildly
with the requirements for the device. If the requirement is that the device should alert the
user if the physical device was opened, broken, or altered, tamper resistance is important. If
the requirement is that the device should be protected from analysis by an amateur or skilled
security researcher or adversary, architectural security is probably the correct resolution for
the risk.
In either case, the risk of not deploying tamper resistance in the case is such that the user
will not be able to determine if an adversary tampered with the physical device. While this
may not mean much to applications with a robust and hardened hardware and application
security architecture, it will mean a lot to products that offer critical services to its users, such
as medical devices, telematics systems, and home security or automation systems.
V1.1 Page 50 of 84
7.4 Enforce Confidentiality and Integrity to/from the Trust Anchor

All communications to and from the trust anchor should be authenticated and should enforce
confidentiality and integrity. The only exception to this model is if the trust anchor is internal
to the core of the processor. Any external trust anchor, such as a UICC, can only be trusted
if the messages received and sent can be trusted.
To do this, choose trust anchors that are capable of authentication and encryption and
validate that all messages containing answers to challenges are sent confidentially and,
where possible, with verifiable integrity.
UICCs that can be managed with Secure Channel are capable of confidentiality and
integrity. The IoT Service Provider should discuss with the Network Operator whether the
UICC Secure Channel technology can be used to assist with application security. In the
future, eUICC will be capable of application security. Secure Channel may then be used to
facilitate Endpoint application security from the bootloader stage to the network
authentication stage.
While this should seem like a simple exercise, there are subtleties to this process. Testing
each aspect of the communications layer is necessary. Some messages from various trust
anchors, may not be confidential or enabled with integrity. For example, a message that
indicates whether an operation succeeded or failed may seem benign, but must be protected
to ensure that an adversary doesnt send a tailored response, tricking the application.
Some trust anchors may not be capable of integrity in the communications channel. Integrity
is preferred, and should be employed to guarantee a message hasnt been tampered with.
But, doing this requires a base of trust on both the host processor and the trust anchor,
which may not be reasonable for the application.
Since all embedded systems are capable of compromise from a sufficiently equipped
physical adversary, it may be overkill to require a root of trust on both processors simply for
local bus communications. However, in applications where physical security is critical,
integrity should be implemented.
7.4.1 Risk
The risk of not enforcing confidentiality and integrity is an interesting one. This risk can range
from a complete system compromise to benign information gathering. This is because
certain messages can be gamed. For example, if a TCB requests that the trust anchor verify
a messages integrity, it will pass the message over a hardware bus to the trust anchor.
If the trust anchor is internal to the CPU, it is unlikely that an Attacker can alter this message
without sophisticated and expensive equipment. However, if the trust anchor is a separate
chip on the circuit board, there may be an opportunity for the adversary to alter the message
by splicing the circuit and inserting their own hardware. If, for instance, the trust anchor
receives the message and simply responds to the query stating Yes, this message is valid
without any integrity, the TCB will be unable to verify if the message had been manipulated
by an Attacker with physical access to the bus.
Furthermore, even if the response is integrity verified, an adversary with physical access to
the bus can simply compromise the circuit, absorb the message request from the TCB, emit
V1.1 Page 51 of 84
their own trusted message to the trust anchor, and let the real trust anchors response pass
through to the TCB. If the hardware communications bus isnt properly secured, this attack is
possible as well, negating the trust anchors ability to perform its job.
However, expecting both the CPU and the trust anchor to have individual internal trust
anchors creates a paradox. How can a bootable CPU trust itself if the CPU can be changed
by an adversary, yet the CPU has to use its own EEPROM to verify the integrity of the trust
anchor! This creates a conundrum, but one that can be solved.
One solution is to insert a public key into the CPUs ROM. This key can be used to verify the
integrity of messages sent by the trust anchor. If an arbitrary message (to be verified) is
transmitted over the hardware bus to the trust anchor, the trust anchor can respond with a
signed message that includes the original message as a part of the reply. This verifies that
the message did in fact originate from the trust anchor, and that the message being
processed is indeed the message that was expected to be processed. The only concern left
would be to ensure that the nonces used in message padding ensured that the
cryptographic messages were not replayable.
With the above in mind, it is easy to identify that cryptography can fail due to very subtle
issues in not just the cryptography, but the algorithms that support cryptographic
communications. This is why implementing confidentiality and integrity (correctly) is so
important.
7.5 Over the Air Application Updates

Remotely updating an Endpoints application image can be a simple and straight-forward
process. The complexity comes from over-engineering the solution in ways that dont
actually address realistic security flaws. From a persistent-storage perspective, the
engineering process is very simple:
Define a location for the active application image

Define a location for the backup application image (if any)
Define a location for the emergency application image
If a backup application image space exists, update this space with the active image
Cryptographically verify the active image using the signature stored in the TCB
This ensures the storage media isnt corrupted as well as an adversary didnt
modify bits during the write process
Download the new image either in whole or in deltas and its metadata and signature
Patch the active image with the deltas
Verify the cryptographic signature using the TCB
Reboot into the new image
If the process fails at any point, the system should either revert to a backup image to ensure
the application performs as needed, or the emergency system can be used to call home and
notify the IoT Service Ecosystem that a fault has occurred.
The difficulty comes from creating a storage model that addresses two issues:
An Attacker attempting to manipulate the update process

A hardware anomaly
V1.1 Page 52 of 84
Without a backup system or emergency partition, the device will have no choice but to fail.
Because embedded systems typically dont have robust user interfaces, this may present a
significant point of stress between the business and its customers. Failing as eloquently as
possible is imperative not only for user confidence, but for system reliability as well.
It is notable that some Attackers may want to corrupt the update process in purpose, to force
a system into a persistently vulnerable state. For example, if an exploitable vulnerability is
found in the active version of the application, but a patch is available in the newest version of
the application.
The benefit of this model is that even if the Attacker corrupts the network negotiation
process, the back-end system has the opportunity to take note of this event. If the back-end
network identifies that a node is communicating normally except for updates, an alert should
be raised for administration to determine whether that Endpoint node is being abused.
7.5.1 Risk
If the OTA application update process is not properly architected, it can result in adversaries
remotely injecting executable code into Endpoints. If the adversary has a privileged position
on the network, they could potentially affect thousands of Endpoints at once. The result of
the attack could range from simple code execution, to denial of service (bricking the
Endpoints), or completely altering the purpose of the Endpoint device.
7.6 Improperly Engineered or Unimplemented Mutual Authentication

In communications environments, peers speak to each other through the protocols
semblance of identity. This means different things in different contexts, but in every
environment an address of some kind identifies the destination of a message. Any
communications module that implements a given protocol is capable of stating that it is the
owner of a particular address. Even if a particular implementation of a protocol is designed,
or forced, to use the hardware address of a local radio module, there is no rule that states
that a user can physically alter the EEPROM of that module and change the hardware
address. Even if the implementation refuses to allow a user to change the hardware address
dynamically, it can still be manipulated into changing the address. The result of this
functionality is, essentially, spoofing: or the act of taking on another computers identity for
the purposes of intercepting messages destined for that computer.
7.6.1 Client Authentication

All environments are vulnerable to spoofing. For example, any GSM radio can signal that it is
the owner of any given International Mobile Subscriber Identity (IMSI), whether it is true or
not. Any laptop can change its Ethernet address, impersonating other computers on the
Local Area Network (LAN). Regardless of whether the topology traverses a physical or an
airwave space, a communication Endpoints identity can be impersonated.
The protection against this is authentication. For example, in the GSM network, anyone with
the right equipment can claim to own any IMSI they choose. However, cellular carriers
enforce authentication by encoding a cryptographic key into the Subscriber Identity Module
(SIM) that is unique per that subscriber (IMSI). When a GSM device communicates with a
base station stating that it is representing a particular IMSI, the base station will issue a
V1.1 Page 53 of 84
cryptographic challenge that can only be solved by someone with the unique cryptographic
key stored in the SIM card provisioned for that particular identity. If the Attacker cannot solve
the cryptographic challenge, the base station can verify that the Attacker does not represent
the IMSI in question, and can disallow that user from associating with the network.
The model described above depicts client-based authentication. This is the model where the
server subsystem (including base stations) allow clients (Endpoints) to join and leave the
network as long as the clients can cryptographically authenticate their identity. However,
there is an inverse problem that exposes clients to manipulation: server authentication.
7.6.2 Server Authentication

In the GSM model, only Endpoints (called Mobile Stations in GSM) are authenticated.
Endpoints do not authenticate the base stations they connect to. Thus, any base station can
claim to serve on behalf of any cellular carrier. Individuals capable of manipulating or
building a cellular base station may then impersonate any GSM carrier of their choosing. A
custom cellular base station currently costs under 1,000 USD to build, but the resultant
power only allows the interception of messages in the local area. Once the fake tower is
built, the base station can impersonate a local cellular carrier, and intercept phone calls, text
messages, and even data, from Endpoints in the local area.
Newer protocols, such as 3G and LTE, enforce mutual authentication of both entities. This
allows Endpoints to cryptographically verify that the base station is serving on behalf of the
cellular carrier it claims to serve. An adversary must now break the cellular carriers
cryptography to impersonate a base station, significantly increasing the complexity, difficulty,
and cost of an attack.
7.6.3 Cellular Interrogators or Fake Base Stations

There are exceptions to this rule, however, such as cellular interrogators. These devices,
typically used by government contractors, governments, and intelligence services, are
encoded with cryptographic keys provided to these entities by certain cellular carriers, for
purposes of national security. These systems use these keys to either passively intercept bi-
directional communications, or to actively perform man-in-the-middle attacks against specific
targets.
In the modern communications threat model, however, access to this technology is not
limited to actors in the government and intelligence areas. Today, these systems can be built
from parts that are only several hundred US dollars, resulting in a cost-effective fake base
station capable of intercepting or impersonating cellular communications.
7.6.4 Communications Security is Gate-To-Gate Security

Bringing up cellular interrogators helps summarize this section quite adequately by touching
on the idea that communications security is not absolute. It only protects the communication
channel between two entities. These entities, however, act as gates allowing data to pass in
and out of the ecosystems these entities are connected to.
For example, a particular SIM card may be provisioned for use in an industrial control
system such as an oil well monitoring device. A SIM card, by design, is a removable
component. Anyone with physical access to the oil well monitoring device can extract the
V1.1 Page 54 of 84
SIM card and place it in a laptop. If the laptop has software on it that can simulate the
functionality of the oil device, the back-end server will be unable to differentiate between the
actual oil device and the laptop. Yet, the laptop will be authenticated to the cellular network
because of the SIM card! Thus, the cellular network has authenticated the SIM card, but not
the laptop.
7.6.5 Solving For Mutual Authentication

Each peer in an IoT ecosystem must authenticate all other peers that participate in that
ecosystem. To accomplish this, a TCB must be used to ensure that proper cryptographic
architecture is driving the communications technology. Mutual authentication cant occur if
keys are easily exposed to adversaries. Review the TCB section of this document for more
information.
Once authenticated, each peer must encrypt and sign messages sent to other peers in the
network. Each peer that receives a message must cryptographically validate the data prior to
acting on it. Since not all communications protocols are capable of mutual authentication, or
have strong cryptography, it is imperative that the application engineer design a sufficient
protocol that enforces confidentiality and integrity, rather than relying on the communications
protocol.
Even more robust protocols that incorporate mutual authentication, such as LTE, do not
address the security of the infrastructure beyond the cellular communications network. Only
higher layer protocol security can address the risk of weaknesses in infrastructure beyond
the control of the cellular carrier.
7.6.6 Risk
The risk of not adhering to strong application security is that the Endpoint must trust the
security of the communications layer. As depicted in this recommendation, it may not be
adequate to solely trust the network to resolve the security issues in the application. Even if
the MNO can be trusted, the messages may pass through multiple pieces of networking
infrastructure not owned or controlled by the MNO before the data reaches servers owned
by the IoT Service Provider. Therefore, the IoT Service Provider risks anyone with control of
those systems intercepting, altering, or manufacturing messages to or from Endpoint
systems.
7.7 Privacy Management

An imperative aspect of IoT technology is their ability to connect the physical world to the
digital world. The result of this is a gap in privacy, as the users physical environment is
directly associated with the things they like and view online. This may cause undesirable
effects over time.
As a result, it is important that IoT Service Providers consider the privacy of their consumers
and develop Privacy Management interfaces that are integrated into both the Endpoint,
where possible, and the product or services web interface.
This technology should allow the user to determine what attributes of their privacy are being
utilized by the system, what the Terms of Service are, and the ability to turn off the exposure
of this information to the business or its partners. This granularity and opt-out system will
V1.1 Page 55 of 84
help to ensure that users have the right and the ability to control the information that they
share about themselves and their physical world.
7.7.1 Risk
The potential risks of not protecting consumer privacy are many. Issues from stalking,
harassment, profiling, threats, and more, are realistic and practical results of not protecting
users data.
7.8 Privacy and Unique Endpoint Identities

Each Endpoint is known digitally by a fingerprint. This fingerprint is composed of addresses,
serial numbers, and cryptographic identities that are unique to the specific Endpoint.
However, these tokens may also directly associate a device to a particular customer,
location, or service. In many situations, this is undesirable. For example, smart phones can
be tracked because the phones built-in Wi-Fi address was used when actively scanning for
802.11 access points. These addresses could then be tracked as they travelled from location
to location. This would allow anyone able to associate a particular Wi-Fi address with a
particular user and watch their movements around the world. To combat this, smart phone
software manufacturers generated random Wi-Fi client addresses when scanning for access
points, making it nearly impossible for phones to be tracked in this fashion.
IoT Endpoints can be tracked similarly through Bluetooth Low Energy (BLE) addresses,
802.15.4 addresses, Wi-Fi, or even cellular IMSI. Where possible, the IoT Service Provider
should develop their Endpoint technology in such a way that a random radio address is used
to connect to new environments, allowing the users privacy to stay intact.
This is also true of cryptographic keys, such as SSH public keys. While users typically want
their public keys to be known to the public, cryptographic public keys on Endpoints will
expose the users identity of a particular Endpoint, which is not desirable. Instead, the user
should be able to select whether they want their identity known when they are connecting to
a new environment.
7.8.1 Risk
Not adequately mitigating this risk will allow users with mobile Endpoints to be tracked as
their devices leave and join networks. This opens up significant gaps in privacy that legal
teams, legislators, and even insurance companies are currently analysing. Not adequately
implementing privacy to diminish the potential for tracking may open up a new IoT Service
Provider to legal consequences in the near future.
7.9 Run Applications with Appropriate Privilege Levels

Applications running on an Endpoint typically do not require super-user privileges. Most
often, applications require access to device drivers or a network port. While some of these
devices, ports, or other objects may require super-user privileges to initially access them, the
super-user privileges are not required to perform subsequent operations. Thus, it is best
practice to only use super-user privileges at the start of the application to gain access to
these resources. Then, super-user privileges should be dropped.
V1.1 Page 56 of 84
Dropping super-user privileges is a common process that is well documented, and has been
implemented exceptionally well in applications such as the Secure Shell (SSH), apache2,
and other well engineered servers. The process usually encompasses:
Starting the application with elevated privileges
Accessing all resources that require elevated privileges
Identifying a user identity (for example, UNIX User ID and Group ID) that the
application should run as
Fully changing the processs identity to the target user/group ID, thus removing
super-user privileges from the running application
A more complex model can be seen in the SSH implementation of privsep, which runs a
privileged service whose sole purpose is to bootstrap the main application under a target
user/group identity. This way, if the service exits it can be restarted easily without the
compromise of privileged resources.
For more information see: SSH Privilege Separation:

http://www.citi.umich.edu/u/provos/ssh/privsep.html
7.9.1 Risk
Running applications with elevated privilege levels can result in a full system compromise if
a single application is compromised. Since super-user privileges grant an application full
access to the entire running system, there is no way to contain an adversary once they
compromise such an application. Dropping privileges helps contain the adversary, and limits
their ability to increase their privilege within the embedded system. This may be the
difference between a full system compromise and a minor annoyance.
7.10 Enforce a Separation of Duties in the Application Architecture

Applications running on an Endpoint should have different user identities associated with
each unique process. This ensures that if one application is compromised, a separate
application on the same Endpoint cannot be compromised without a successful second
attack. This extra step required on behalf of an Attacker is often a critical hindrance to the
overall exploit development process and increases the cost and complexity of an attack
against an Endpoint.
For example, a network service that allows a user to retrieve information about the state of
the Endpoint must not also be able to manipulate the TCB over the same process. That
capability would be out of scope relative to the purpose of the service. These two distinct
operations should be handled in separate applications, and ran under separate user IDs on
the local Operating System, helping to separate the duties of the application, and reduce the
risk of abuse if one component were compromised.
To implement this correctly, memory protection must be enabled in the underlying hardware
architecture, and the operating system must have a concept of privilege levels. Unprivileged
software must be restricted from accessing privileged resources, such as drivers,
configuration files, or other objects.
V1.1 Page 57 of 84
Services should make requests to access privileged resources, but through a constrained
API such as a system call, to ensure that all messages are well formed and fit the
requirements of the security architecture.
The concept of multi-tiers of privilege is a half a century old concept. However, in embedded
systems, it is often overlooked as users are not allowed to log into the console and run their
own applications. As a result, all services are often deployed as a privileged user. However,
this is flawed.
Each application or service must be implemented using a custom privilege. In most

environments, this is a separate user identity. This separation of duties by enforcing different
user identities ensures that if one service is compromised it cannot not directly affect the
resources used by another service on the same system. To compromise other services and
users, secondary exploits must be found in the local operating system to elevate privileges.
This requires planning and a sound application architecture that utilizes privilege separation
correctly.
7.10.1 Risk
If a separation of duties is not enforced, any compromise to a single service on the Endpoint
will result in a compromise of the entire device, because each service or application running
on the device will share the same user and/or group identity. If the recommendation is
implemented, a low privileged service that is compromised over the network will not
immediately result in compromise of the entire system.
Because this recommendation is simple to implement, it is critical to the security of IoT

Endpoints. It should be noted that it often takes a large amount of expertise to remotely
compromise a network service. If the adversary is also required to elevate privileges by
implementing a kernel level exploit, or another secondary exploit, to gain control of the full
system, the adversary may not have the time, skills, or equipment to execute the attack.
Increasing the difficulty of an attack with a simple configuration change such as this will go a
long way toward ensuring the longevity of the device.
In addition, as compromised services can be detected through process monitoring and other
analytics, any service compromise can alert the Service Ecosystem that a device
compromise has been detected. This allows administrators to act to secure the system
before a full system compromise has been achieved. This also allows administrators to
diagnose and patch the vulnerable software prior to rampant abuse of the particular
vulnerability. This gives the business a significant edge against even skilled Attackers.
7.11 Enforce Language Security

Programming languages have varying degrees of security, depending on the purpose of the
language and how high level it is. Some languages provide constructs for limiting access to
raw memory, and enforce constraints around how memory is used. The engineering team
should identify a language that is capable of providing security to the application run-time or
resultant binary.
The compiler or run-time should be security hardened, where possible, to restrict the
potential for a vulnerability to be abused by an adversary. In a well defined run-time
V1.1 Page 58 of 84
environment, even an easy-to-trigger programming flaw can be extremely difficult to fully

exploit. This presumes that security enhancements are used to protect the way the
application executes, accesses memory, and is supported by the operating systems security
enhancements.
7.11.1 Risk
The risk of not hardening the programming language and resultant application is an easy-to-
exploit application. Some programming systems such as PHP are notoriously buggy and
should never be used by a professional engineering team. Other languages, such as Python,
are suitable for production environments, but have subtle security risks that must be
evaluated. Thus, the volatility of the resultant risk can be anywhere from a critical level to a
benign level. The engineering team must use the risk assessment and threat modelling
process to sufficiently evaluate what language is best for their production environment.
8 Medium Priority Recommendations

The medium-priority set of recommendations encompasses the set of recommendations that
are relevant depending on the design choices of the Endpoint technology. For example,
enforcing Operating System Level Security Enhancements is only valid if there is an
Operating System running on the Endpoint. If the Endpoint is composed of a monolithic
kernel application, or an embedded Real-Time Operating System (RTOS) with a single
embedded application, the recommendation may not apply. Where recommendations do
apply to the Endpoint design, they should be implemented.
8.1 Enforce Operating System Level Security Enhancements

Applications running on an Operating System should be designed to use (either
transparently, or intentionally) the security enhancements of the underlying Operating
System and Kernel. This includes technologies such as:
ASLR
Non-Executable Memory (Stack, Heap, BSS, ROData, etc.)
User-Pointer Dereference Protection (UDEREF)
Structure Leakage (information disclosure) Protection
Each operating system used in an embedded system will provide different variations and
combinations of these technologies, sometimes under different names. Determine what the
operating system and kernel are capable of providing, and enable these technologies, where
possible, to enhance the security of applications.
The challenge comes from identifying what each Operating System is capable of. For
example, applications running on platforms that have no Memory Management Unit (MMU)
may not be capable of ASLR. However, the equivalent of UDEREF can be enforced even in
environments with only a Memory Protection Unit (MPU). Evaluate which technology is being
used and its capabilities, and determine what level of security can be achieved through the
combination of architecture, kernel, operating system, and application protections.
V1.1 Page 59 of 84
8.1.1 Risk
Not enforcing this recommendation will result in an application run-time environment that is
substantially easier to exploit. These enhancements will significantly constrain the number of
adversaries that are capable (if at all) of developing a reliable exploit for a vulnerable
service.
Thus, if an application developed by the organization has a security flaw that could be
abused to gain remote code execution capabilities, the potential for abuse can be negated
by enforcing ASLR, NX, UDEREF, and other technologies. This will limit the ability for an
Attacker to develop an exploit in a reasonable amount of time, as the exploit developer will
be required to use advanced and challenging techniques that must be customized against
each individual target. This increases not only the difficulty, but the time and expense
required to achieve a fully working exploit.
Without these enhancements, a fully working exploit can be developed using off-the-shelf
and freely available software within hours.
8.2 Disable Debugging and Testing Technologies

When a product is being developed it is often enabled with debugging and testing
technologies to facilitate the engineering process. This is entirely normal. However, when a
device is ready for production deployment, these technologies should be stripped from the
production environment prior to the definition of the Approved Configuration.
The Approved Configuration that a product is deployed with should never contain
debugging, diagnostic, or testing interfaces that could be abused by an adversary. Such
interfaces are:
Command-line console interfaces
Consoles with verbose debugging, diagnostic, or error messages
Hardware debugging ports such as JTAG or SWD
Network services used for debugging, diagnostics, or testing
Administrative interfaces, such as SSH or Telnet
All such technologies should be disabled in the Approved Configuration.
Serial ports that can be removed by the system should also be physically removed from the
circuit board. However, many times serial ports such as UART/USART are enabled over
hardware pins on the microcontroller or processor. If these pins are still enabled as a
console, an adversary can simply tap the pins to interact with the console. Removing the
physical serial port itself, such as a DB9 interface, does not disable the console.
Furthermore, debugging ports such as JTAG and SWD should not simply be disabled via
software. These devices should be disabled by altering security fuses or locks. Disabling
these technologies from software offers a window of opportunity for an adversary to connect
to JTAG, SWD, or a similar hardware debugging interface prior to the time at which the
V1.1 Page 60 of 84
software disables the interface. This window of opportunity is often sufficient enough for an
adversary to succeed.
8.2.1 Risk
Without implementing this recommendation, organizations open themselves up to extraction
of critical secrets from the central processing unit. This may allow adversaries to load their
own firmware into NVRAM or EEPROM, and allow them to extract or alter critical secrets
that further compromise the IoT network or device.
Disabling debugging ports is a critical step to ensuring the integrity of the IoT product or
service. However, it is important that the organization evaluate the risk of disabling these
technologies and weigh them against the benefit of being able to diagnose and debug
problems identified in the field. It may be significantly more challenging to remediate
production-level flaws in the product if there is no way to debug a running system.
8.3 Tainted Memory via Peripheral-Based Attacks

Processing systems rely on consistency to ensure that the output of algorithms is predictable
with respect to a set of given inputs. Processing systems also expect components to act
reliably, and that for every bit written, that bit is stable and unaltered until it is changed by the
processor. Within closed systems, this theory is applicable. When anomalies to this model
occur, they can compromise, or simply damage, a processing environment.
Information security presents the class of anomalies purposefully induced in order to gain
access to objects that otherwise would be inaccessible. An abusable window for the
induction of anomalous behaviour beneficial to an adversary is Direct Memory Access
(DMA). Put simply, DMA is a technology that processors can use to allow external
components (peripherals) to gain access to main processor memory without interference by
the CPU. In other words, the CPU can grant a peripheral direct access to a region of
memory. This peripheral may then read or write to that region of memory.
If the processor does not properly restrict the region of memory usable by the peripheral, the
peripheral may have access to more of main memory than is required for the intended
functionality. In other words, if the peripheral (say, an Ethernet controller) is allotted a DMA
region intended for use as a circular buffer for received Ethernet frames, and the DMA
region allotted comprises the entire expanse of main memory, the firmware on the Ethernet
controller may now arbitrarily read and write to all system memory. The CPU will have no
way to block the Ethernet controller firmware from writing to memory.
The result of this attack is two-fold. Data can be leaked from main memory and encoded into
network packets or application information for covert or immediate exfiltration. Alternatively,
an Attacker could covertly insert a backdoor (malware) into main memory by overwriting an
applications executable code.
From the processors perspective, there is little it can do to identify whether an overly
permissive window of memory has been abused by a malicious peripheral device. To
combat this attack, identify whether the processor used in the Endpoint system is capable of
restricting DMA to small predictable regions of memory. If so, ensure that each region of
memory is defined per each peripheral device that requires it. Do not enable arbitrary
windows memory, where possible, to peripherals.
V1.1 Page 61 of 84
Some processors may not allow granular restriction on the size or location in linear or virtual
memory of a DMA window. As DMA attacks should be considered a realistic threat to IoT
Endpoints for critical applications, evaluate whether it makes sense to consider an
alternative processor with more granular features.
For platforms that expose ports such as IEEE1394, Thunderbolt, Express Card, or other
ports that allow direct access to Peripheral Component Interconnect (PCI) DMA, canned and
cost effective attacks are already available.
For platforms where a DMA based attack requires abuse of a local hardware component, the
difficulty will certainly increase, but it is not out of the scope of an offense-based security
engagement to reflash a peripherals firmware in order to subvert DMA for compromise of a
local Endpoint. Cost, time, and expertise will however be a factor, making the actor in this
case likely a sponsored (paid) adversary.
8.3.1 Risk
Choosing not to restrict the ability for DMA to be abused by external components may
subject the platform to a full compromise, or, at least, the extraction of key secrets, privacy-
centric data, or intellectual property from the Endpoint.
8.4 User Interface Security

IoT Endpoints that have user interfaces such as touch screens, rich displays, or alternative
interface technologies, must be able to render information to the user and take information
from a user in a secure manner.
While attributes of the user interface, such as passwords, have already been covered in this
document, there are some more subtle issues that must be discussed:
Alerting systems
Action confirmation
When an anomaly has occurred, such as physical tampering or an application behaving in

an unintended fashion, the user should receive a visible alert. Alternatively, the user should
be able to review alerts from the system from within the User Interface.
Furthermore, all actions performed by the device that are driven by encodings or seamless
transitions from one interface to another should be confirmed by the user. An example of this
is if the device camera reads a QR code, or a NFC or RFID interaction requests that the
device connect to an URL. In these cases, the user should be prompted to confirm the action
and validate that the action performed is desirable. The user should be given the option to
cancel the action. The user should be able to view all details about the given action,
including the full URL that will be connected to.
8.4.1 Risk
If this recommendation is not implemented, users will be vulnerable to attacks that cannot be
detected. While some system designers appreciate the seamlessness of transitioning from
an RFID chip to, say, the corresponding product website, there may be undesirable effects
of this behaviour. Users could be forced to view undesirable materials without their consent,
V1.1 Page 62 of 84
or users could be tricked into visiting websites or performing actions that weakens their
security posture or privacy.
Also, users that have a difficult time reviewing their Alerts may not understand the risks of
using a potentially tampered device. This may decrease the users physical security and
could put them at risk.
8.5 Third Party Code Auditing

Any time a section of code, such as a bootloader, is a critical component in constructing a
secure run-time platform, it must be audited for risks. If a bootloader can be manipulated by
an adversary into executing untrusted code, or into bypassing the authentication sequence,
it is rendered useless. This would negate the finances, time, and experience utilized by the
organization in the deployment of this technology, nullifying the engineering expense.
A gap in security in this area may also result in a competitors advantage against the
business through spoofing, API abuses, data interception, device cloning, and even device
rebranding. Thus, it is imperative that critical sections of code be audited by an approved
third party, to ensure that technology is not at risk of abuse. Therefore, to find an information
security team adequate to perform the audit, evaluate what types of code will be audited.
Typically, in this model, that means: C, Assembly, and possibly C++ or Java.
Identify a team that is well versed in these languages, as well as the underlying architecture.
While many information security teams perform source code auditing, not many of them may
perform auditing on the particular platform used by the IoT business. Each platform has
subtle differences, and it is best to use a team with familiarity with the platform being used.
8.5.1 Risk
While hiring third party consultants to evaluate internally developed technology can be a
challenge, it is a requirement for security. This is because engineers developing technology
must be able to show that their architecture is provable. This is difficult to do if the engineers
developing the architecture are the only ones reviewing it. Engineers tend to visualize their
code base from the architecture that they have attempted to design and implement, not from
the actual implementation. Thus, third party eyes are often needed to find subtleties in the
architecture and implementation that could cause gaps in security.
8.6 Utilize a Private APN

In cellular networks, an Access Point Name (APN) acts as a private network configured
specifically for a set of authenticated devices. Typically, a private APN (also called secure
APN) is a private network only accessible to authenticated devices associated with a
specific business. By utilizing an APN, businesses can restrict what Endpoints are allowed to
connect to their service infrastructure over the cellular network. This helps to reduce the
amount of users that have direct access to IoT services in the back-end infrastructure.
Other attributes of a private APN can help diminish the potential for rogue Endpoints to
abuse the IoT ecosystem. Firewalls can limit what services or computers can be connected
to from the APN. A well configured APN will disallow Endpoints from making direct
connections to each other, which disallows a compromised Endpoint from migrating
horizontally through the network infrastructure to other Endpoints.
V1.1 Page 63 of 84
Engage with the cellular carrier or Mobile Virtual Network Operator (MVNO) that the
organization is working with to determine what technologies are available within the secure
APN. Other services such as monitoring, blacklisting anomalous devices, and tying user
identities to actions, may be available.
8.6.1 Risk
Utilizing a private APN can alleviate many types of attacks. For example, private APNs allow
the business to reduce the amount of connections that can be made from the Endpoint
directly to the Internet. Endpoints should never be allowed to directly connect to untrusted
Internet resources. Only partner organizations should be trusted, and those services should
be authenticated.
Without the use of a private APN, compromised Endpoints can communicate to any Internet
service or protocol without restriction. This may allow an adversary to abuse the Endpoint in
order to launch a secondary attack on separate infrastructure. This could involve a denial of
service (DoS) attack, or could help facilitate a more dangerous attack against another
business, government, or civilian.
It is notable, however, that a private APN does not mitigate the risk of an adversary
compromising the communication link between the Endpoint and the private APN. In
addition, the private APN only acts as a gateway to the back-end services, and doesnt
enforce any security between the APN and the back-end services on the IoT Service
Providers private network. These potential gaps in security must be addressed separately,
regardless of the improvements that are granted through the use of a private APN.
8.7 Implement Environmental Lock-Out Thresholds

Components within an embedded system are designed to be used within certain
environmental thresholds. This includes voltage levels, current draw, ambient or operating
temperature, and humidity. Each component is typically rated for certain windows of
approved levels. If the device is subjected to states above or below a given window, the
component may act erratically, or behave in a fashion that is useful to an adversary.
Therefore, it is important to detect changes to these environmental levels to determine

whether the device should continue running, or if it should power off. It should be noted,
however, that powering off may be a desired effect, and that the adversary may abuse this
engineering decision to leverage a denial of service. The engineering team should evaluate
this model to determine if it is more beneficial to shut down or more beneficial to attempt to
stay online.
Regardless, the model usually incorporates
Brown-out and Black-out detection, when voltage drops too low
Voltage ceiling circuitry protection to ensure voltage levels dont exceed a threshold
Current limiting circuits to ensure current draw cannot drop or exceed certain levels
Internal temperature monitoring for CPUs, MCUs, and other components that monitor
internal levels
V1.1 Page 64 of 84
Optionally, humidity levels can be assessed to determine if the environment is

becoming too humid or too arid
Temperature is extremely important as high temperatures can indicate a circuit problem

triggered by the user, the environment, or even a hardware or software issue. Monitoring the
temperature will allow the operating system or application to shut down resources (or the
entire device) to ensure a fire or another issue isnt caused by the Endpoint.
Low temperature levels also change the behaviour of a device. This may slow a circuit down,
or cause its components to react in unexpected ways. This may be useful to an Attacker if
temperature can cause a predictable anomaly that affects the application or circuitry in a
beneficial manner.
Difficulty in lock-out thresholds manifests when analysing temperature and humidity. Voltage
and current levels should be mitigated by Brown-out and Black-out circuitry either on the
circuit board or in the processor. Since engineers will be able to look up the numbers related
to a chips voltage and current thresholds, they can easily implement protections for these
issues.
For temperature and humidity, the decision to act is a bit more challenging as these levels
can be manufactured by an adversary without touching the physical device. In the case of
temperature, levels that may be indicative of a pending safety event must cause the device
to take adequate measures to lower the temperature. However, in critical environments such
as Industrial Control Systems or Medical Devices, the device should attempt to continue
performing critical operations, where possible. If levels exceed a certain defined point that
engineers and business leaders agree upon, only then should the device shut down.
8.7.1 Risk
For voltage and current draw, the risk of abuse is related to glitching and other side-channel
attacks that can benefit from changes in these levels. If Brown and Black-out detection is
implemented on the processor, the risk of abuse is lowered. Otherwise, the risk is related to
spikes in voltage or current that could cause safety issues with the physical device, or allow
an Attacker to instrument glitching (and similar) attacks to subvert the security of the
components.
These issues should be remediated through the use of circuitry on the PCB that protects the
components against anomalous spikes or drops in voltage or current.
For environmental level changes that are dramatic, the risk is related to the safety of the
user. High temperatures caused by excessive CPU usage or other anomalies can cause
burns, chemical burns, or even fires.
8.8 Enforce Power Warning Thresholds

Endpoints that provide critical services to the user must be enabled with a warning threshold
that indicates power-related events. These events may include:
Low battery state
Critically low battery state
V1.1 Page 65 of 84
Black-out events
Brown-out events
Switch to battery back-up events
The user must be warned in a sufficient amount of time to allow them to compensate for the
loss of power. This could be accomplished by enabling an LED that denotes a particular
power state such as green for OK, orange for Low, and red for Critical.
Systems that are connected to alternating current mains power should be configured to warn
the user when black-out or brown-out events have occurred. Also, the Endpoint should log
these events in persistent memory to ensure that the user and administration can retrieve
the information at a later time. The information should be time stamped.
The challenge in this process is identifying at what rate the batterys power is being depleted
and the extra energy required to notify the user of a change in power state. This can all be
achieved through electrical engineering, and should not be too challenging of a process for
experienced engineering firms.
8.8.1 Risk
Without a well defined power warning system, the users will be unable to adequately prepare
for potentially critical power events. While this may be benign in the case of simple devices
such as pace counters, timers, and other wearable devices, more critical devices such as
personal trackers, telematics systems, and home security systems can be seriously
impacted by the loss of power.
V1.1 Page 66 of 84
8.9 Environments Without Back-End Connectivity
8.9.1 Method
Endpoints, especially Gateways, or Endpoints acting as Gateways, must be capable of
enforcing communications security even in environments where connectivity to the back-end
network is unavailable. Regardless of whether this lack of connectivity is temporary or not,
the Gateway or Endpoint must be capable of enforcing security as if the back-end system
were available.
To achieve this, the TCB must be used to authenticate all peers that the Endpoint must
communicate privacy-centric, configuration, or command data to. The TCB can be used to
ensure that messages sent and received from peers are being sent and received from an
entity that has been provisioned by the same organization. This reduces the likelihood that
an adversarial device is being communicated with.
Interoperability can still be achieved by communicating with other devices that cannot be
authenticated. However, the type of information that is communicated to these devices
should be restricted to inter-operational and non-sensitive classes of data.
The challenge comes from deciding what Endpoints to authenticate and what Endpoints to
communicate with in clear-text. The organization must decide what types of data are
classified and should be kept from unauthenticated peers. Once this classification of data is
achieved, the organization will be able to determine what peers are reasonably trustworthy
even without the assistance of the core IoT services.
8.9.2 Risk
The risk of deploying solutions to communication-less environments is that it opens up an
opportunity for competition to abuse the infrastructure. Competitors can undercut the
business by offering interoperability and using connection-less sites as a proving ground.
Instead, the organization can choose to allow interoperability, but to a point. Certain core
intellectual property and services can then be reserved for only authenticated peers that are
validated through the use of a TCB. This helps to reduce the exposure of the business to
intellectual property problems and adversarial competitors.
8.10 Device Decommissioning and Sunsetting

All Endpoint devices have a lifecycle, as discussed elsewhere in this document. Some
devices must be decommissioned due to a user cancelling their subscription, while other
devices must be decommissioned due to anomalous or adversarial behaviour. Regardless of
the reason, the business must be prepared to decommission the device securely using their
TCB and communications model.
Sunsetting, as discussed elsewhere in this document, is the process of decommissioning an

entire network of devices and the services supporting those devices. A product or service
that has been deprecated by a business, or a business deciding to shut down, must sunset
their devices and network in order to diminish the risk of abuse by adversaries taking over
the sunsetted network.
V1.1 Page 67 of 84
To accomplish this, the TCB and supporting protocols should be used. Generally, the
process is to:
Create a Decommission message from the Service Ecosystem
Tailor the message to the unique Endpoint receiving the message
Sign the message using the Decommissioning PSK or asymmetric key
Push the message down to the Endpoint
Receive a message from the Endpoint cryptographically acknowledging

Decommission
Invalidate the Endpoint in the Authenticated Device list
Disallow further communication from this Endpoint
On the device side, the application running on the software should
Connect to critical back-end services over Service Ecosystem
Query the service for critical messages
Receive the Decommission message
Verify the message signature using the TCB and the trust anchor
Generate the Acknowledgement message and cryptographically sign it using the

Personalized PSK or asymmetric key
Perform the Decommission operation
Send the message back to the critical service
It is important that the message be signed and prepared for transmission prior to
decommissioning, as the decommissioning process includes the invalidation and removal of
security keys from the trust anchor. Because of this process, the keys used to sign the
decommission message will not be available. The service requires the reception of a
message that is integrity verifiable to ensure that the Endpoint did indeed receive and
process the message.
The difficulty with this process is primarily in that decommissioning a potentially

compromised device presumes that the device has not been compromised to the point
where it will reject the decommission command. If it has been sufficiently compromised, it
may not honour the decommission command.
As a result, it is imperative that the backend system running in the Service Ecosystem
invalidate the Endpoint from being able to communicate with critical services. If the device
does attempt to interact with networked peers or critical services, the backend system
should raise an alert and let the administration know that the anomalous event has occurred.
V1.1 Page 68 of 84
8.10.1 Risk
The risks of not implementing decommissioning and sunsetting are many, from complete
takeover of an entire network by adversaries to allowing compromised devices to continue
using networked services. The most common risk is associated with users that have ended
their subscription with an IoT Service Provider. If these users are not decommissioned from
the network, they may be able to continue communicating with other peers in the IoT
Endpoint network, or may be able to access services that should no longer be accessible to
the user. This incurs a cost on behalf of the IoT Service Provider, who must pay for the
bandwidth, CPU time, and storage in the Service Ecosystem.
8.11 Unauthorized Metadata Harvesting

Modern IoT is designed to bridge the physical world with the digital world. In this modern
model, the effects of technology are potentially far more invasive than in the past. Using
metadata, companies or private individuals can intentionally track and monitor the behaviour
of random or specific consumers.
Metadata analysis is used when communication between two network entities is encrypted,
but protocol structures that identify the type of message or identity of the sender and/or
receiver are exposed. This metadata can be used to derive intent.
Consider the scenario where automobiles emanate messages containing metadata that is
attributable to a specific consumer. Anyone with the ability to track (either locally or remotely)
these pieces of metadata may be able to monitor the consumers movements, and then
derive behaviour or intent from these movements. If there are security flaws that are
exploitable in the vehicles telematics system, it may be possible to track and target a
specific consumers telematics system, putting them at risk of physical harm.
Legal organizations and insurance companies are concerned about how these risks will
impact the future of automotive finance, and are beginning to get involved in legislation and
standards that will determine how engineers must design telematics equipment. This change
will eventually trickle down to the less active IoT verticals, as more technology is developed.
To combat metadata harvesting, encrypt as much data as possible and use unique binary
identifiers for communication modules. Enforce a policy that disallows external users from
being able to use the IoT systems API to derive hardware serial numbers and other
trackable identities from user profiles. Where possible, disallow the structure of a message
from being exposed to third parties. Do not allow actions, activities, or behaviours to be
exposed to third parties. Enforce confidentiality and integrity on all data that relates to user
privacy.
8.11.1 Risk
Using weak communications security may enable data or metadata harvesting that
endangers an end-user or exposes end-user privacy. As insurance agencies are building a
case for enforcing end-user privacy requirements in technology, the business may put itself
at risk if it doesnt take responsibility for the data their devices generate.
V1.1 Page 69 of 84
9 Low Priority Recommendations

Low priority recommendations encompass the set of recommendations that apply to risks
that are extremely costly to combat, or are unlikely to affect the Endpoint design. While these
recommendations are valuable, and the information detailed within the recommendations is
important, the mitigation or remediation strategies discussed may be out of scope with
respect to the business. Evaluate each recommendation and determine whether the risks
described are relevant or important to the business and its customers. If the customers
require these risks to be addressed, apply the recommendations.
9.1 Intentional and Unintentional Denial of Service

For radio communications, there is a constant threat of jamming, or the intentional
broadcasting of noise or patterns that can be used to scramble legitimate signals. As radio
signals are simply composed of electrons flying through space in a specific pattern, it is fairly
easy to concoct a series of signals that interrupt or mangle the pattern that forms
communications data.
Typically, the goal of such an attack is simple disruption, to disallow or deny service to
legitimate users. In other cases, the abuse may be more purposeful. For instance,
communications protocols that have no authentication mechanism can be spoofed. To
achieve this, the actual signal must be jammed so that the adversarys spoofed signal is
more likely to reach the intended target.
An example of this is Global Positioning Systems (GPS) spoofing. Civilian GPS signals lack
encryption and authentication as it is, essentially, a plaintext broadcast signal that anyone
can receive. It is also a relatively weak radio signal and is easily attenuated by
environmental anomalies such as Ultra High Frequency (UHF) pre-amplifiers for television
receivers and microwaves.
For devices that require location information to function properly, a jammed GPS signal can
result in a reliability risk that can cascade into an information security risk, especially if
spoofing is subsequently employed.
To combat jamming and other forms of intentional denial of service (DoS) attacks, develop a
robust communications protocol that focuses on methods to devalue breaks in service. The
network should detect whether devices have suddenly or abnormally left the network. Each
Endpoint should say goodbye when it intends to leave the network. If it doesnt, the
anomaly should be noted for statistical analysis.
In addition, communication security keys should be renegotiated every time a device re-joins
the network. The same communications security key should not be used. It should be
bootstrapped by the same asymmetric cryptographic key, but any symmetric key derived
from key negotiation should be novel per each communications session.
Unintentional jamming can occur on a radio for many reasons: environmental conditions that
disallow signal propagation, malfunctioning equipment, or even adjacent equipment
operating at the same frequency. Regardless of the underlying reason, engineers that rely
on radio communications expect that there will be temporal conditions that cause signal
degradation or loss. These losses must be compensated for through the design of the
application and network communications protocol.
V1.1 Page 70 of 84
Developers are recommended to read the GSMAs Connection Efficiency Guidelines [9]
which contains advice on how to protect against unintentional Denial of Service attacks and
provide guidance regarding Device Host Identity Reporting (DHIR).
9.1.1 Risk
Failing to combat the risk of intentional DoS will result in abnormal or insecure Endpoint
behaviour. If the Endpoint always uses the same session key, this may be a way adversaries
could abuse network architecture to gather information about the symmetric key used to
secure the communications. Properly building a secure session after each disconnected
session is imperative toward the security of the Endpoint communications.
9.2 Safety Critical Analysis

Most Internet of Things products will incorporate some aspect of the physical world with
digital technology. As a result, it is likely that a human will make a decision in the physical
world based on information provided from an IoT Endpoint. Alternatively, an IoT Endpoint
may make a decision that affects the physical world with information obtained through the
digital world.
Therefore, it is imperative that IoT Service Providers evaluate their product from a safety
perspective to determine if, how, and when human life may be affected by the technology. If
adequate safeguards are not put into place to ensure the technology cannot be abused in
order to cause physical harm, their customers may be put at risk.
To help resolve the issue of safety, have a discussion with the IoT Service Providers
executive, legal, and insurance teams. Ensure that these teams understand the capabilities
and limitations of the technology used in the product or service. Determine whether these
technologies can meet the needs of the business and offer the customers the level of safety
necessary for the intended application.
9.2.1 Risk
Clearly, the result of not taking the time to evaluate the impact of the product or service on
the safety of the customers could result in the loss of revenue, unexpected accidents, or
even loss of life.
9.3 Defeating Shadowed Components and Untrusted Bridges

Components on the physical circuit typically do not use any semblance of confidentiality and
integrity when communicating with each other or the central processing unit. As a result, any
adversary can read or write data transmitted on these buses. The effect of this gap in
communications security is the ability for an adversary to impersonate legitimate devices on
the physical circuit. If the adversary chooses, they can impersonate a critical component
such as NVRAM, RAM, or even a trust anchor.
The goal of this attack would be to bypass the security employed between two components
on the bus. A typical example of this scenario is utilizing this weakness to bypass the
integrity validation process of analysing an application image stored in NVRAM. When the
CPU retrieves memory stored in NVRAM, the Attacker can use a pass-through system to
provide the real memory contents to the CPU. When the application running on the CPU has
verified the integrity of the application image, the Attacker may then instrument the
V1.1 Page 71 of 84
communications on the physical bus to selectively swap out NVRAM contents that are
beneficial to the Attacker. In other words, the CPU verifies one application image (the
original image) but then loads the Attackers image into RAM and executes it.
One way to safeguard against this attack is:
Load NVRAM contents into RAM
Validate the application image loaded into RAM
Execute the code directly in RAM or cache the contents in RAM
It should also be noted at this point that an Attacker could subvert RAM as well, weakening
this process. However, performing a man-in-the-middle attack against RAM is far more
complex and costly than an attack against NVRAM because the speed of the bus and
access patters are far faster and more erratic than with NVRAM, which is primarily accessed
in blocks.
Alternatively, the Attacker can create checksums for smaller regions of validated NVRAM
contents and periodically check the signatures from NVRAM. If the checksums differ, then
the content is being manipulated. This may succeed, but has a lower success potential
because the adversary may only manipulate a small amount of data that isnt randomly
checked by the running application.
It should be noted that while the best way to guard against this attack is to validate the
contents of NVRAM then load it into executable RAM, there is no full solution for this
problem. The cost of securing physical components is so high that it is not practical to
resolve this attack in a more full way, unless the customer requires such security
assurances.
This attack is even more simplistic when a more basic physical communications protocol,
such as I2C, is used. Buses such as I2C are essentially physical broadcast systems. Thus,
any component sitting on the I2C bus can pretend to be any other component. This will allow
an adversary to impersonate other devices on the bus that dont enforce confidentiality and
integrity on the communications channel. Where this is a concern, enforce confidentiality and
integrity in the application protocol used on top of the physical bus protocol.
9.3.1 Risk
The risk of not implementing a solution at all will result in the ability for an adversary to
bypass integrity checks in the application. This will allow the Attacker to compromise the
application being executed by more privileged code, such as bootloaders or TCBs.
It should be noted, however, that this attack is far less likely than simpler attacks against the
bootloader. Performing a man-in-the-middle hardware attack against components like
NVRAM, or high speed components like RAM, is challenging, complex, and currently
expensive. While it will always be possible for an adversary to subvert an embedded system
in this fashion, it may be too cost-prohibitive to do so.
Thus, loading code into RAM and verifying the integrity may be a reasonable solution that
will bypass the majority of attacks, if any.
V1.1 Page 72 of 84
Also, for the reasons described above and more, cryptographic keys should not be kept in
insecure privileges such as these. They should be stored in a trust anchor and used by the
TCB, not stored in media such as NVRAM that could be impersonated or compromised.
9.4 Defeating a Cold Boot Attack

A cold boot attack [REFERENCE] is a physical attack strategy against computer systems
that extracts secrets from a running computer by removing the physical memory from the
computer, and placing the memory in a secondary system controlled by the adversary. The
benefit of this attack is that the Attacker can run a custom operating system that dumps the
contents of RAM to permanent storage. This will allow the Attacker to comb through the
retrieved data and determine if there are security related tokens that can be used. This may
include:
Cryptographic secrets or private keys
Login credentials (user names and passwords)
Personally Identifiable Information (PII)
Access tokens for web services
The goal of the attack is to compromise secrets that allow the Attacker to gain long-term
access to a resource that would otherwise be out of their reach. For example, breaking the
cryptographic algorithms used in the most recent standard of TLS would be impossible for
the average Attacker. However, compromising the private client certificate used in a mutual-
authentication TLS service would allow the Attacker to simulate the client from a more
convenient system.
To succeed in this attack, the Attacker must be able to remove the RAM from the target
computer system without the bits stored in the chip changing. As detailed in the research
paper, this can be accomplished by cooling the memory chips. However, the RAM must be
easily removable. If the RAM is soldered to the circuit board, this would vastly complicate the
attack and require the Attacker to use a soldering gun to extract memory, potentially
damaging the contents.
It is important to note that scrubbing memory at shutdown is always useful, and is advised,
to enhance the privacy of an Endpoint. Yet, a cold boot attack can occur at any time, even
while the system is running. Therefore, scrubbing memory may be useful, but may not
succeed in defeating a real-world attack.
A more effective mitigation for this attack is to process security-centric actions using RAM
that is internal to the CPU. Many CPUs, MCUs, and MPUs have a small amount of internal
SRAM that can be used by a running application. If the application limits the use of critical
security tokens (such as private keys) to this internal RAM, the contents of removable (or
external) RAM will have less value to an Attacker.
9.4.1 Risk
Not consider the risk of a cold boot attack may cause critical security keys to be extracted
using a simple attack model. If the security keys are universal to all Endpoints in the IoT
Service Providers ecosystem, a large compromise may be possible.
V1.1 Page 73 of 84
For more information see - https://citp.princeton.edu/research/memory/
9.5 Non-Obvious Security Risks (Seeing Through Walls)

Despite enabling and enforcing mutual authentication, confidentiality, and integrity in the
communications network, traffic patterns can directly correlate to events. When data is
trafficked in response to certain physical events, a correlation can eventually be made
between physical events and data. This may allow an adversary to monitor for signal
patterns, then derive meaning from the patterns whether or not the adversary has direct
access to the plaintext data.
An example of this is home automation technology that reacts based on a users physical
presence in a particular room. An adversary capable of remotely monitoring the
communications system may be able to observe how many users are in a particular home,
where the users are in the home, and who the user is, solely by watching patterns of
communication between IoT Endpoints, gateways, and back-end systems.
The adversary may be able to easily differentiate between a highly populated home, and
homes where only one individual is home alone, and where that individual is within the
home. Insurance companies and legal entities will need to understand how this potentially
increases risk to homeowners and other tenants in the living space.
Combatting this risk can be difficult. The most common and simplest model for doing so is to
send samples at a pre-defined rate, regardless of whether there is a user present to take
samples from. If confidentiality and integrity is enforced, disallowing remote adversaries from
evaluating the datas plaintext, an observer will be unable to differentiate between a sample
containing user activity and an empty sample.
There are concerns with this model, however, such as increased spectrum saturation,
increased power consumption for low-power or battery-enabled technology, and the
increased processing level required to decrypt, verify, and interpret the empty sample
packets.
An alternative is sending samples at random intervals, with varying bursts. This type of
pattern is less costly, less power hungry, and requires less processing power. Yet, it still may
be possible to observe subtle changes that indicate user presence. For example, any truly
entropic system is fully random and unpredictable. User behaviour, however, is entirely
predictable. If a user enters a room and the sensors in that room react and begin to send
data to peer IoT Endpoints in the network, the introduction of consistent behaviour may
indicate the presence of a user.
Any team developing technology that is subject to this type of risk should investigate the
potential effects of the exposure of privacy, and consult with the legal team to determine
whether the technology would have an effect on the businesss legal stance or insurance
model.
9.5.1 Risk
If the IoT Service Provider does not evaluate their technology from the perspective of
potential privacy exposures and security risks, the architecture may need to be substantially
overhauled in order to compensate for the risks that must be addressed. Instead of trying to
V1.1 Page 74 of 84
make costly adjustments to the architecture at a later time, engineer these solutions into the
product at the start of the engineering phase, or, as early as possible.
9.6 Combating Focused Ion Beams and X-Rays

A Focused Ion Beam (FIB) is a manufacturing instrument commonly used in semiconductor
evaluation. The technology is capable of inspecting and altering circuits at the nanometre
level, which allows analysts to identify faults in manufacturing, and to test circuit patches
before altering the fabrication process.
In information security, a FIB can be used to tap internal busses for the purpose of
intercepting data trafficked over internal components. In addition, a FIB can be used to alter
internal circuitry, which changes how the internal component will operate, allowing an
adversary to bypass a security restriction.
Almost all devices are subject to attack by a FIB. Yet, only certain devices will be ran
through a FIB process. This is because a FIB itself is an extremely costly technology, at
approximately 1,000,000 USD per unit. Because of the high cost of the technology, few
organizations have such a device in their toolkit. Furthermore, the device isnt automated. It
requires a high degree of skill to manipulate, as well as a very high degree of expertise in
semiconductor analysis, to be usable. Thus, the realistic cost of a FIB is far beyond a simple
million-dollar figure, and extends into the multi-millions of dollars for the utility itself, and the
education, and salary and expertise of the user.
Organizations are available for outsourcing, however. As reverse engineering is largely

legal, organizations will provide semiconductor attack services for customers that are
interested in reverse engineering a device. These engagements cost anywhere from 10,000
USD to 1,000,000 USD depending on the level of customization and expertise required to
attack a particular component. For example, an outsourcing company would have a
playbook to bypass protections on a common chip. But, a custom FPGA solution with novel
security locking technology would cost far more as no existing playbook would be defined. A
new process would be required to use the FIB successfully, costing substantial time and
money.
Some new technologies, such as modern trust anchor variants, claim resistance from FIB
probes. While there is some validity to these claims, any hardware protection that isnt
dynamic (and most arent) will result in a playbook after a sufficient amount of time has been
put into analysing bypass techniques. Therefore, these new claims may be valid, but may
only be valid for a window of time.
Therefore, to compensate for invasive but almost-always-successful attack technologies

such as these, it is imperative for the engineering organization to design a security strategy
that doesnt pin its success on the trust anchor alone. Instead, a sufficient protocol must be
designed that uses the technology as a base trust anchor, but personalizes each Endpoints
cryptographic keys such that no compromise of a single device results in a compromise of
the entire network of Endpoints.
Consider the scenario where an adversary must use a FIB to extract cryptographic from
every Endpoint they wanted to target. This would quickly become an extremely costly
proposal, and would be out of scope with regard to almost any adversarys budget. Since
V1.1 Page 75 of 84
these attack methodologies cannot be sufficiently mitigated, they must be devalued, to

diminish risk through architecture, not through obscurity.
9.6.1 Risk
The risk of a FIB is that cryptographic secrets and other intellectual property can be
extracted from a component, even a security-hardened component. Since defeating a FIB in
a cost-effective manner for consumer IoT is impractical, the organization must alter their
strategy for protecting Endpoint systems or risk a complete compromise of the Endpoint
ecosystem.
9.7 Consider Supply Chain Security

The security of any computing system starts with the raw components that the circuit board
are composed of. The silicon, cryptographic tokens, read-only-memory (ROM), firmware,
and other core attributes of an embedded system all contribute to the security of such a
system. If any one of these components are tampered with, the entire system could be
subject to a security compromise.
As a result, IoT Service Providers who are conscious about security must take into account
the source of their components, their assembly, and the fulfilment process used to ship the
assembled technology. If the process used to generate the technology isnt carefully
planned, a single point of failure in the process could result in a critical security failure.
Consider the following issues:
Where and by whom is the silicon manufactured?
Has the silicon design been analysed by a credible third party information security
team?
Will the silicon be fabricated in a secure facility?
How will the EEPROM or NVRAM be populated with an executable image, such as a
bootloader?
Is the process for flashing the executable image secure?
How will the executable image be delivered to the manufacturer?
Is the executable image verified once it has been flashed onto EEPROM or NVRAM?
How are cryptographic secrets provisioned on the chip(s)?
If secrets are generated at the manufacturer, are they using a proven RNG to
generate the keys?
Are all of the security keys unique per the TCB recommendations?
How are the cryptographic secrets shared with the IoT Service Provider? Securely?
How are the unique chip identifiers (serial number, etc.) correlated with the
cryptographic secrets, and shared with the IoT Service Provider?
V1.1 Page 76 of 84
While choosing a more security facility to build and assemble a product may incur a greater
cost, it may be an imperative step for the organization. This depends on the product use
case, the intended deployment environment, the intended customer, and other factors such
as human safety, military applications, and critical infrastructure deployments. Where human
life can be impacted by the resultant technology, the supply chain should be assessed for
gaps in security.
9.7.1 Risk
Without supply chain security the organization is subject to many risks, some of which may
be entirely unexpected, and yet critical to the business:
Endpoint cloning (illegal manufacture)
Theft of technology (competitors stealing from and undercutting the Service Provider)
Credential theft (data interception or impersonation attacks)
Injection of implants (malicious back doors that may be activated at a later time)
9.8 Lawful Interception

Lawful interception is the act of legally intercepting or manipulating communications between
a customer and a service provider. This can work in one of two ways. First, the most typical
scenario is that a law enforcement agency will submit a legal request to a carrier and ask for
access to metadata or actual data from communications made by a specific subscriber.
Second, the law enforcement agency will ask the IoT Service Provider for access to a
specific subscribers data and/or meta-data. In the scenario where the agency requests
access via the carrier, the IoT Service Provider may never be notified that there is a
problem, depending on the scope of the legal request. Thus, the service provider must be
ready to either implement, or comply, with a legal request made by such an agency.
Therefore, the provider should identify what privacy issues may result from a law
enforcement request, and should be ready to provide information relevant to the
organizations legal model and privacy policy, within their respective legal capabilities.
In the recent past, businesses such as Google, Apple, and other large entities have adopted
warrant canaries to legally let users know when a secret request has been made to the
company on behalf of an agency. The business may remove a phrase, image, or other
artefact that is representative of not being in contact with lawful intercept agents. The
removal of this object is indicative, of course, of a request being made.
9.8.1 Risk
Not readying the business for a lawful intercept request puts the business at a disadvantage
if such a requirement is placed on the business. The business may need to comply to the
request, but may not have the legal infrastructure or privacy policies ready, potentially
putting them at risk.
Not readying the Endpoint protocol and IoT platform for adequate confidentiality and integrity
will enable the communications to be intercepted at the network side without the businesss
knowledge. This can put the business at risk of the user data being leaked, or associated
V1.1 Page 77 of 84
with an event such as the Snowden NSA leaks, substantially decreasing the publics trust in
the organizations ability to secure user data.
V1.1 Page 78 of 84
10 Summary
In summary, almost every security risk in an IoT product or service can be combatted by a
well defined architecture, intelligence to identify risks before and during security related
events, and policies and procedures to handle such events. By analysing which high-level
security concepts are important to the IoT Service Provider, frequently asked security
questions can be reviewed. This should guide the engineering team toward which
recommendations are most relevant to resolve gaps in their security architecture.
As the team progresses in its architectural definition, it can review standalone

recommendations as their security questions and concerns become more unique to their
own implementation.
Overall, every engineering team will face very similar risks. It is imperative that the
organization choose to share their concerns with their peers to build common a
knowledgebase for both risks and remediation strategies. Together, our organizations can
build both technology and knowledge to assist each other in building security into the future
of IoT.
V1.1 Page 79 of 84
Annex A Example Using Generic Bootstrap Architecture
The overall security level of a multi hop network is defined by the weakest link in the chain.
Thus the local link between IoT Endpoint and an Gateway needs to be secured with a
comparable level of security as the wide area network to keep the same overall level of
security.
One candidate technology for achieving this is Generic Bootstrap Architecture (GBA) [17]
which can be used for both authentication as well as data integrity. This is based on pre-
shared keys which are then used to generate time-limited keys (tokens) as a basis of both
authentication and encryption.
Authentication is the process of determining whether someone or something is, in fact, who
or what it is declared to be. In the IoT space, where billions of Endpoints will be active,
determining what communication behaviour is genuine and trustful is paramount. The
mechanism established to create this trust relationship needs to satisfy the requirement of
being scalable and maintainable. Furthermore, the variety of IoT Services imposes the
requirement that the authentication mechanism can be adapted to accommodate those
different services and still maintain a common infra-structure. A mechanism that has proven
itself over time is network authentication based on the SIM. This authentication infrastructure
has the virtue of providing not only authentication, but also encryption capabilities based on
pre-shared secrets. The explosion in the number of Endpoints and the global reach of IoT
makes the use of SIM limited because of network roaming and the security weakness of
being able to physically remove a SIM from an un-attended Endpoint. The arrival of
technologies like the Embedded SIM provides a practical infrastructure for authentication
based on pre-shared secrets, extending the current SIM based network authentication.
Also, IoT growth is most likely to happen in the form of capillary networks (the PAN as
shown in the example configurations 2, 3 and 4 in the previous section of this document).
These capillary networks are swarms of Endpoint devices connected to a Gateway. Most of
these Endpoint devices will be lightweight Endpoint devices (i.e. they do not contain a SIM
nor cellular connectivity). These lightweight Endpoint devices will nonetheless require
authentication and encryption capabilities. In capillary networks the principal responsibility of
authentication lies on the Gateway, reducing the number of complex SIM based Endpoint
devices on the overall network. This authentication and security should be extended from the
Gateway to the Endpoint device, creating then a secure channel from the given Endpoint
device to the IoT Service Platform.
SIM based authentication is meant to serve a single application, i.e. the authentication of a
unique Endpoint device for network attachment. Endpoint devices will have a multitude of
services, each with different and exclusive need for authentication. A framework that extends
the network authentication to multiple services is required. One framework that was
designed for this purpose is GBA, Generic Bootstrapping Architecture. GBA leverages on
the SIM based infrastructure to generate time-base share keys between devices and
Network Application Functions (NAFs). GBA is an authentication method standardized by
the 3GPP in the 3GPP specification TS 33.220 [17]. The method enables the authentication
of a device with a 3GPP subscription to a service. The credentials of the subscription are in
the device, usually stored on a SIM, such as a Universal Integrated Circuit Card (UICC), or
V1.1 Page 80 of 84
as remotely managed credentials, stored and managed on an embedded SIM (eUICC) for
example, such as the GSMA specified Embedded SIM (eUICC) [5].
The advantages of this framework are:
Mutual authentication based on either PSK uniquely between a device and a Network
Application Function or shared key-based UE authentication with certificate-based NAF
authentication (TS 33.222) [18].
Credentials can be secured in a Trusted Environment
If eUICC is used, the credentials can be changed OTA.
Scalability. The complexity and economic cost of maintenance increases linearly with
the number of devices, since authentication is built inside the framework.
Data integrity. The time-base generated keys during authentication can be used for
establishing TLS-PSK tunnels, making this connection will provide very strong data
integrity and confidentiality.
V1.1 Page 81 of 84
Annex B Tutorial on use of UICC cards in an IoT Service

The UICC as standardized in ETSI TS 102 221 is a smart card platform (a programmable
tamper-resistant secure element) providing an interoperable secure file system interface and
secure application framework to UICC hosting devices. ETSI TS 102 221 provides a
framework for a UICC hosting device to discover relevant applications on a UICC, and each
UICC application corresponds to a known set of provisioning and configuration information
as well as operational procedures (such as authentication or key derivation) that can be
supported by the hosting device according to its needs.
In IoT context, UICC can be available in multiple Form Factors and environmental operating
ranges as specified in ETSI TS 102 671. In its simplest embodiment, the UICC is typically
owned by a network operator and only hosts one Network Access Application (SIM
application as per 3GPP TS 51.011, USIM as per 3GPP TS 31.102, CDMA CSIM as
specified by 3GPP2, WiMAX SIM, etc.). In this case, the UICC provides a standardized
holder to host security provisioning and configuration information as well as cryptographic
procedures on a mobile device to enable network access, with additional mechanisms to
remotely manage the content of the UICC, using ETSI TS 102 225 / TS 102 226. The mobile
network ecosystem has procedures in place to ensure secure personalization and
deployment of UICCs under control of the network operator, resulting in the establishment of
individual shared symmetric keys between UICC hosting devices and the infrastructure.
One important feature of UICC platform is the support of isolated Security Domains that
enables multiple stakeholders in a complex ecosystem to each be assigned their own area
on a UICC and manage its content in confidentiality from other stakeholders. This
functionality is inherited through ETSI TS 102 226 from GlobalPlatform Card Specification
[15] Amendment A. Therefore, in an IoT context, a single UICC enables multiple
stakeholders to store and administer their own credentials independently from one another.
In general, a UICC can hold several Network Access applications (with only one being active
at any given time), and potentially other applications securing access to more elaborated
services, such as ISIM applications for IMS access (as specified in 3GPP TS 31.103) or, in
the case of IoT Services, 1M2M SM applications specified in Annex D of oneM2M TS-0003.
A 1M2MSM application can support direct provisioning of dedicated IoT Service/ application
credentials, as well as derivation from pre-existing network access credentials on the UICC
using the GBA mechanism specified by 3GPP. It further enables an IoT Service Provider to
customize the cryptographic procedures according to its specific needs, e.g. to support
specific service authentication mechanisms.
A single UICC can also hold multiple 1M2MSM applications, enabling the confidential
deployment of symmetric keys dedicated to each IoT Service Provider. A UICC owner
(typically a network operator or OEM manufacturer in IoT context) may share space on its
UICC with IoT Service Providers that request it, so that the accredited UICC personalization
chain and infrastructure that enables secure deployment of network access credentials can
also be leveraged by IoT Service Providers to deploy their own credentials.
Where IoT application security rely on asymmetric cryptography, custom UICC applications
can similarly be used to facilitate the deployment of public/private key pairs, as needed for a
specific IoT Service. Such UICC applications need to be specified and supported on hosting
devices on an IoT application specific basis.
V1.1 Page 82 of 84
Annex C Document Management
C.1 Document History

Authority Company
1.0 08-Feb- New PRD CLP.13 PSMC Ian Smith
2016 GSMA
&
Don A. Bailey
Lab Mouse
Security
1.1 07-Nov- References to GSMA IoT Security PSMC
Ian Smith
2016 Assessment scheme added.
GSMA
Minor editorial clarifications.
C.2 Other Information

Type Description
Contact Ian Smith GSMA
V1.1 Page 83 of 84
Official Document CLP.14 - IoT Security Guidelines for Network Operators
IoT Security Guidelines for Network Operators

Version 1.1
07 November 2016

Copyright Notice
Disclaimer
Antitrust Notice
V1.1 Page 2 of 27
Table of Contents
1 Introduction 3
1.1 Overview 3
1.2 Document Structure 3
1.3 Document Purpose and Scope 3
1.5 Definitions 4
1.6 Abbreviations 5
1.7 References 6
2 IoT Service Assets That Network Operators Can Protect 9
3 Network Security Principles 10
3.1 Secure Identification of Users, Applications, Endpoint Devices, Networks
and Service Platforms. 10
3.2 Secure Authentication of Users, Applications, Endpoint Devices, Networks
and Service Platforms. 11
3.3 Provide Secure Communication Channels 11
3.4 Ensure Availability of Communication Channels 12
4 Privacy Considerations 14
5 Services Provided by Network Operators 14
5.1 Secure Subscription Management Procedures 14
5.2 Network Authentication and Encryption Algorithms 17
5.3 Security of Fixed Networks 18
5.4 Traffic Prioritisation 18
5.5 Backhaul security 18
5.6 Roaming 18
5.7 Endpoint and Gateway Device Management 21
5.8 Other Security Related Services 23
Annex A Document Management 26
A.1 Document History 26
A.2 Other Information 26
V1.1 Page 2 of 27
1 Introduction
1.1 Overview
This document provides top-level security guidelines for Network Operators who intend to
provide services to IoT Service Providers to ensure system security and data privacy.
Recommendations are based on readily available systems and technologies that are
deployed today.
1.2 Document Structure

This document is a document intended for Network Operators and IoT Service Providers.
Readers of this document may also be interested in reading the other documents in the
GSMAs IoT Security Guidelines document set [11], as shown below.
CLP.11
Document CLP.14
IoT Security
CLP.12 CLP.13
+ Guidelines for
Network
Ecosystem Ecosystem
Figure 1- Structure of the GSMA IoT Security Guidelines Document Set
1.3 Document Purpose and Scope

This document should act as a checklist in the supplier agreements between IoT Service
Providers and their Network Operator partner(s).
The scope of the document is limited to:
Security guidelines related to IoT Services.

Recommendations pertaining to the security services offered by a Network Operator.
Cellular network technologies.
This document is not intended to create new IoT specifications or standards, but will refer to
currently available solutions, standards and best practice.
This document does not address the security issues associated with the interfaces and APIs
implemented on the IoT Service Platform (or IoT Connectivity Management Platform) in
order for the IoT Service Platform to share its data with end users (for example to share data
V1.1 Page 3 of 27
with an end user via a smartphone or PC application) or other entities within the ecosystem.
Such interfaces and APIs shall be secured using best practice internet security
technologies and protocols.

The primary intended audience of this document is:
Firstly, Network Operators who wish to provide services to IoT Service Providers.
Secondly, enterprises and organisations who are looking to develop new and
innovative connected products and services (the so called Internet of Things)
utilising cellular of fixed line networks. In this document we refer to these enterprises
as IoT Service Providers.
1.5 Definitions
Term Description
Device Host Identify A capability for an Endpoint device to report host information to a Network
Reporting Operator. See GSMA Connection Efficiency Guidelines [17]
Diameter is an authentication, authorization, and accounting protocol for
Diameter
computer networks. See IETF RFC 6733 [18]
An IoT Endpoint is a physical computing device that performs a function
or task as part of an Internet connected product or service. See section 3
Endpoint
of CLP.13 [29] for a description of the three common classes of IoT
devices, and examples of each class of Endpoint.
A complex endpoint device that typically bridges between Lightweight
Gateway Endpoint devices (connected via a local network) and a wide area
network. See CLP.13 [29] for further information.
devices and appliances connected to the Internet through multiple
networks. These devices include everyday objects such as tablets and
Internet of Things
consumer electronics, and other machines such as vehicles, monitors
and sensors equipped with communication capabilities that allow them to
send and receive data.
IoT Connectivity A system, usually hosted by the Network Operator, to allow the self-
Management management of IoT subscriptions and price plans by the IoT Service
Platform Provider.
Any computer program that leverages data from IoT devices to perform
IoT Service
the service.
The service platform, hosted by the IoT Service Provider which
IoT Service Platform
communicates to an Endpoint to provide an IoT Service.
Enterprises or organisations who are looking to develop new and
IoT Service Provider innovative connected IoT products and services. The provider could be a
Network Operator.
Typically a constrained device (e.g. sensor or actuator) that connects to
Lightweight Endpoint
an IoT Service via a Gateway device.
V1.1 Page 4 of 27
Term Description
The operator of the communication network that is connecting the IoT
Network Operator
Endpoint device to the IoT Service Platform.
A Secure Element Platform specified in ETSI TS 102 221 that can
support multiple standardized network or service authentication
UICC
applications in cryptographically separated security domains. It may be
embodied in embedded form factors specified in ETSI TS 102 671.
A telecommunications network that extends over a large geographical
Wide Area Network
distance.
1.6 Abbreviations
Term Description
AKA Authentication and Key Agreement
APDU Application Protocol Data Unit
API Application Programming Interface
BGP Border Gateway Protocol
CEIR Central Equipment Identity Register
CERT Computer Emergency Response Team
DNS Domain Name System
DoS Denial of Service
DPA Data Processing Agreement
EAB Extended Access Barring
EAP Extensible Authentication Protocol
EID eUICC Identity
ETSI European Telecommunications Standards Institute
EU European Union
eUICC Embedded UICC
FASG Fraud and Security Group
GCF Global Certification Forum
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GRX GPRS Roaming eXchange
GSM Global System for Mobile communication
GTP GPRS Tunnelling Protocol
HLR Home Location Register
HSS Home Subscriber Server
ICCID Integrated Circuit Card Identity
V1.1 Page 5 of 27
Term Description
IMEI International Mobile station Equipment Identity
IMSI International Mobile Subscriber Identity
IPSec Internet Protocol Security
L2TP Layer Two Tunnelling Protocol
LBO Local Break Out
LPWAN Low Power Wide Area Network
LTE Long-Term Evolution
M2M Machine to Machine
MAP Mobile Application Part
MME Mobility Management Entity
OSS Operations Support System
OTA Over The Air
A pseudo-acronym, originally meaning PCS Type Certification Review Board, but no
PTCRB
longer applicable.
RAN Radio Access Network
SAS Security Accreditation Scheme
SGSN Serving GPRS Support Node
SMS Short Message Service
SoR Steering of Roaming
SS7 Signalling System No. 7
UMTS Universal Mobile Telecommunications Service
USSD Unstructured Supplementary Service Data
VLR Visitor Location Register
VPN Virtual Private Network
VoLTE Voice over LTE
WAN Wide Area Network
1.7 References
ETSI TS 102 Secured packet structure for UICC based applications
[1]
225 www.etsi.org
ETSI TS 102 Remote APDU structure for UICC based applications
[2]
226 www.etsi.org
V1.1 Page 6 of 27

Characteristics of the Universal Subscriber Identity Module (USIM)
3GPP TS
[3] application
31.102
www.3gpp.org
Open Mobile API specification
[4] N/A
www.simalliance.org
OMA Device Management
[5] OMA DM
OMA FUMO OMA Firmware Update Management Object
[6]
GSMA Remote Provisioning Architecture for Embedded UICC Technical
[7] SGP.02 Specification
www.gsma.com
ETSI TS 102 Extensible Authentication Protocol support in the UICC
[8]
310 www.etsi.org
3GPP TS Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in
[9] 23.122 idle mode
www.3gpp.org
NISTIR 7298 Glossary of Key Information Security Terms
[10]
www.nist.gov
GSMA CLP.11 IoT Security Guidelines Overview Document
[11]
www.gsma.com
n/a Introducing Mobile Connect the new standard in digital authentication
[12]
www.gsma.com/personaldata/mobile-connect
3GPP TS 3GPP 34 series specifications
[13]
34.xxx www.3gpp.org/DynaReport/34-series.htm
[14]
[15]
GSMA FS.04 Security Accreditation Scheme for UICC Production
http://www.gsma.com/aboutus/leadership/committees-and-
[16]
groups/working-groups/fraud-security-group/security-accreditation-
scheme
GSMA CLP.03 IoT Device Connection Efficiency Guidelines
[17]
www.gsma.com/iot/iot-connection-efficiency-guidelines-v4/
IETF RFC Diameter Base Protocol
[18]
6733 www.ietf.org
ETSI TS 102 Machine-to-Machine communications (M2M);
[19] 690 Functional architecture
www.etsi.org
TR-069 CPE WAN Management Protocol
[20]
www.broadband-forum.org
V1.1 Page 7 of 27

n/a OpenID Connect
[21]
openid.net/connect/
n/a FIDO (Fast IDentity Online) Alliance
[22]
fidoalliance.org/
ETSI TS 102 Mobile Commerce (M-COMM); Mobile Signature Service; Web Service
[23] 204 Interface
www.etsi.ord
n/a National Institute of Standards and Technology (NIST)
[24]
www.nist.gov
n/a European Network of Excellence in Cryptology (ECRYPT)
[25]
www.ecrypt.eu.org
GSMA CLP.12 IoT Security Guidelines for IoT Service Ecosystem
[26]
www.gsma.com
IETF RFC Improved Extensible Authentication Protocol Method for 3rd Generation
[27]
5448 Authentication and Key Agreement (EAP-AKA) tools.ietf.org/html/rfc5448
IETF RFC Extensible Authentication Protocol Method for Global System for Mobile
[28] 4186 Communications (GSM) Subscriber Identity Modules (EAP-SIM)
tools.ietf.org/html/rfc4186
GSMA CLP.13 IoT Security Guidelines for IoT Endpoint Ecosystem
[29]
www.gsma.com
n/a Wireless Security in LTE Networks
[30] www.gsma.com/membership/wp-
content/uploads/2012/11/SenzaFili_WirelessSecurity_121029_FINAL.pdf
GSMA CLP.17 IoT Security Assessment Checklist
[31]
www.gsma.com/iot/iot-security-assessment/
V1.1 Page 8 of 27
2 IoT Service Assets That Network Operators Can Protect

The security features that need to be implemented to adequately protect IoT Service assets
are specific to each service. Therefore, it remains the responsibility of the IoT Service
Provider to use proper risk and privacy impact assessment processes to derive their specific
security needs. Network Operators and IoT Service Providers often share similar security
requirements to protect their assets, therefore it makes sense for them to leverage on
common security solutions rather than implementing duplicate (and potentially redundant)
security infrastructures. Moreover, in many cases the Network Operators will be also the IoT
Service Provider.
The security services provided by Network Operators can provide a critical role in securing
the assets used to provide an IoT Service. These can include:
IoT Service data being sent between an IoT Endpoint device and the IoT Service
Platform this includes both primary privacy-sensitive data (e.g. end user related
data) and commercially exploitable data (e.g. such as actuator control data) which
may also have some secondary privacy impact.
The security assets (IMSI, keysets etc.) and network configuration settings (APN,
timer values etc.) used within Endpoint devices (including Gateway devices).
IoT Service Providers business-sensitive information, including brand reputation,
customer/user data under company responsibility, strategic information, financial
data, health records, etc.
An IoT Service Providers business infrastructures, service platforms, corporate
networks and other private network elements.
Public (i.e. shared) datacentre infrastructures provided by the Network Operator that
are used by the IoT Service. This can include public services, hosted capabilities,
virtualization infrastructures, cloud facilities, etc.
Communications network infrastructure, including radio access networks, core
network, backbone networks, basic service functions (DNS, BGP, etc.), access to and
aggregation of fixed and cellular networks, etc.
V1.1 Page 9 of 27
3 Network Security Principles

Proper and reliable security mechanisms must be implemented by Network Operators in
their networks.
In this section it is described how networks can provide value within the IoT ecosystem.
The most fundamental security mechanisms provided by a communication network are:
Identification and authentication of the entities involved in the IoT Service (i.e.
Gateways, Endpoint devices, home network, roaming networks, service platforms).
Access control to the different entities that need to be connected to create the IoT
Service.
Data protection in order to guarantee the security (confidentiality, integrity, availability,
authenticity) and privacy of the information carried by the network for the IoT Service.
Processes and mechanisms to guarantee availability of network resources and
protect them against attack (for example by deploying appropriate firewall, intrusion
prevention and data filtering technologies)
3.1 Secure Identification of Users, Applications, Endpoint Devices, Networks

and Service Platforms.
Identification consists of providing unique identifiers to the entities within the IoT Service,
and correlating these electronic identities to real-world, legally-binding identities.
Within a cellular connected IoT Service, Endpoint devices are identified using IMSI and/or
IMEI (EIDs may also be used for devices with eUICCs). Networks are identified using
network codes and country codes. Each method of providing identity has varying levels of
secure assurance associated with it.
Identity plays a crucial role in the process of authentication as secure authentication can only
be achieved on the basis of a secure identity. It is therefore essential that the identities (for
example an IMSI, IMEI or ICCID) issued and used within an IoT Service are securely
protected against unauthorised modification, impersonation or theft.
One practical problem an IoT Service Provider may face is that their IoT Service may require
communications with many IoT Service Platforms, each of which may require a separate
unique identification. Each identity used to establish a communications link to each IoT
Service Platform will then need to be securely provisioned, stored and managed by the IoT
Service.
Where appropriate for the IoT Service, Network Operators recommend the use of UICC
based mechanisms to securely identify Endpoint devices. Network Operators can also
extend the secure storage functionality provided by the UICC to the IoT Service Provider to
enable them to store additional IoT Service related identities on the UICC. This technique
can be applied to both cellular and non-cellular Endpoint devices (e.g. EAP-AKA [27]).
Single sign-on services could also be provided by Network Operators to allow Endpoint
devices to establish and prove their identity once, and then connect to several IoT Service
Platforms without further inconvenience. The security trade-offs and risks of using such a
service must be considered across the multiple platforms.
V1.1 Page 10 of 27
3.2 Secure Authentication of Users, Applications, Endpoint Devices,

Networks and Service Platforms.
According to NIST [10], authentication is verifying the identity of a user, process, or
Endpoint device, often as a prerequisite to allowing access to resources in an information
system.
Network Operators can provide services to ensure that the users, applications, Endpoint
devices, networks and service platforms associated with an IoT Service are securely
authenticated.
Authentication has a related property that of non-repudiation. According to NIST [10], a

definition of non-repudiation is: assurance that the sender of information is provided with
proof of delivery and the recipient is provided with proof of the senders identity, so neither
can later deny having processed the information. Non-repudiation, depends on asserting
that authenticity has not been violated when identifying the source of that transaction or
message.
3.3 Provide Secure Communication Channels

Network Operators provide communications security mechanisms for wide area cellular and
fixed networks providing the reassurance of best-in-class communications integrity,
confidentiality and authenticity. Where appropriate, Network Operators can provide and
manage secure connections to enterprise networks using Virtual Private Networks (VPNs)
and encrypted internet connections.
The purpose of a secure communication channel is to ensure that the data being sent over
the channel is not processed, used or transmitted without the knowledge and consent of the
data subject. Encryption technologies play a crucial role in secure data transmission by
assuring the properties of confidentiality, integrity and authenticity. Encryption must be
appropriate to the system being designed and deployed taking into account Lightweight
Endpoint devices, network aspects (such as satellite backhaul constraints) and the service
being provided.
Network Operators can provide IoT Service Providers with data encryption services to
ensure communication integrity and network resilience.
Network Operators traditionally provide public telecommunications infrastructure or a mixture

of public or private network infrastructure. Many Network Operators can ensure that the
customer/user data that transits their public network infrastructure is encrypted between the
point that the data enters the public network infrastructure to the point that it leaves the
network. Where required, Network Operators can also assist IoT Service Providers to deploy
or derive their own encryption credentials to ensure confidentiality of IoT data during transit
through the Network Operators infrastructure.
Network Operators can provide their customers with private networks where dedicated
communication channels are provided for the use of a single customer to ensure that no
data traverses a public network such as the Internet. Such private networks could be
created:
V1.1 Page 11 of 27
1. By using a tunnelling protocol such as Layer Two Tunnelling Protocol (L2TP) and
secured using protocols such as Internet Protocol Security (IPsec), or
2. By creating a dedicated network for the IoT Service by deploying a separate instance
of the core network with shared radio network as per the example shown below.
Figure 2 - Example of Private Network Configuration
3.4 Ensure Availability of Communication Channels

According to NIST [10], availability is the property of being accessible and useable upon
demand by an authorized entity.
Network Operators can provide IoT Service Providers with available networks. The most
fundamental mechanisms provided by Network Operators to provide network availability are
as follows:
3.4.1 Use of Licenced Spectrum

GSMA Network Operator members will operate networks using dedicated licenced spectrum
under the terms of the licences issued by their national regulators. Use of licensed spectrum
ensures interference from other radio technologies is kept to a minimum as any
unauthorised use of this spectrum will be subject to prosecution. Network operators together
with national regulators will seek out any unauthorised sources of interference to ensure
network availability is not impacted.
Use of licenced spectrum, which provides the Network Operator with dedicated radio bands
in which to operate their network, ensures that careful network coverage and capacity
planning can be undertaken by the Network Operator to ensure maximum network
availability to their customers.
3.4.2 Implementation of Standardised and Proven Network Technologies

GSMAs Network Operator members implement standardised network technologies such as
GSM, UMTS and LTE as specified by standards bodies such as the 3GPP. The use of
standardised technologies not only assures interoperability between Network Operators, it
V1.1 Page 12 of 27
also ensures the standard is subject to maximum scrutiny during its creation to ensure the
robustness of its technology.
3.4.3 Implementation of Tested and Certified Network Technologies

Many parts of a Network Operators network will be tested and certified according to
international test standards. Complex Endpoint devices and the communication modules
they contain will be subject to 3GPP test specifications [13] via GCF, PTCRB and Network
Operator acceptance testing. Radio Access Networks (RAN) will be subject to 3GPP test
specifications [14] via Network Operator acceptance testing. UICCs will be subject to 3GPP
test specifications [15] via Network Operator acceptance testing and, additionally, may be
subject to GSMA SAS certification [16].
3.4.4 Resilient Network Topographies and Configuration

Network Operators provide resilient networks implementing and building in the necessary
geographic redundancy and isolation to ensure maximum availability with minimum
downtime. All network elements are carefully configured and monitored to ensure strict
quality of service and service level agreements are met.
3.4.5 Real Time Monitoring and Management of Network Resources

Network Operators implement state of the art network operations centres that monitor the
performance of their networks on a 24/7 basis and in real time to manage network traffic,
respond to network demand and fix faults. Additional information can be found in section
4.10
3.4.6 Threat Management and Information Sharing

The GSMAs Fraud and Security Group (FASG) provides an open, receptive and trusted
environment for all Network Operators to share fraud and security intelligence and incident
details in a timely and responsible way. The group assesses the global fraud and security
threat landscape, analyses the associated risks for Network Operators and their customers
and defines and prioritizes appropriate mitigating actions.
3.4.7 Roaming Services

Due to the use of standardised network and Endpoint device technologies and interconnect
services, Network Operators can offer network roaming services, further enhancing network
coverage and availability for their customers.
3.4.8 Endpoint Device Performance Monitoring and Management

Network operators can measure the performance of the Endpoint devices that connect to
their networks to isolate Endpoint devices that may be creating excessive amounts of radio
interference (e.g. do not conform to national regulations) or network signalling traffic (e.g. do
not conform with GSMA Connection Efficiency Guidelines [17]) which, in turn, may be
degrading the performance of the overall network. Endpoint devices can thus be monitored,
disconnected or their firmware may be updated when abnormal behaviour is detected.
V1.1 Page 13 of 27
4 Privacy Considerations
To realise the opportunities that the IoT offers, it is important that consumers trust the IoT
Service Providers who are delivering IoT Services and collecting data about them. The
GSMA and its members believe that consumer confidence and trust can only be fully
achieved when users feel their privacy is appropriately respected and protected.
There are already well-established data protection and privacy laws around the world which
have been applied, and complied with, by Network Operators. Operators believe that it is
possible to apply existing data protection regulations and principles to address privacy needs
in the context of IoT Services and technologies.
However, IoT Services typically involve operators working together with IoT Service Provider
partners. It is important that there is regulatory clarity and legal certainty around IoT Services
and that privacy and data protection regulations apply consistently across all IoT Service
Providers in a service and technology-neutral way.
Network operators should be aware that if they process data in any way they need to sign a
Data Processing Agreement (DPA) with the IoT Service Provider. The data protection and
security practices developed for a given IoT Service should reflect the overall risk to an
individuals privacy and the context in which data about the individual is collected, distributed
and used. Any regulatory interventions should be limited to areas where identified risks
emerge and existing measures are insufficient to address these.
Network operators can draw on their extensive experience in addressing privacy and
security issues and work collaboratively with IoT Service Providers, to embed privacy and
security into IoT technologies and the overall consumer experience. Such collaboration will
ensure IoT Service Providers are able to identify and mitigate the relevant consumer privacy
risks in the context of the service being delivered.
For more information please see the GSMA Mobile Privacy Principles:
http://www.gsma.com/publicpolicy/mobile-and-privacy/mobile-privacy-principles
5 Services Provided by Network Operators

Network Operators can provide IoT Service Providers with secure cellular and fixed wide
area networks (WANs).
This section contains best-practice recommendations when connecting IoT Services to wide
area networks. Where appropriate, the recommendations will be independent of the
technology used, but will also use best practice from cellular and other network types.
5.1 Secure Subscription Management Procedures

This section contains recommendations on how IoT Service Provider subscriptions should
be managed by Network Operators:
The Network Operator or IoT Service Provider should perform an assessment of the
network services that are needed to enable the IoT Service (voice, data, SMS, etc.)
both now and in the future.
V1.1 Page 14 of 27
Based upon this assessment the Network Operator should operate on the principle
of least privilege and provision the IoT Service Providers subscriptions with only
those services required for the specific IoT Service. For example:
o IoT Services that only use data bearers should not be provisioned with
voice and SMS services.
o Where an Endpoint device only connects to a known IoT Service Platform,
the subscription associated with the device should only allow connection to
a known whitelist of IP address ranges (or domains).
o If the IoT Service uses voice or SMS, the use of a preconfigured fixed
dialling list should be considered.
Network Operators should implement secure subscription management processes for

IoT subscriptions that enable critical IoT Services (for example for the subscriptions
associated to critical healthcare services). These services should not arbitrarily be
disconnected.
Network Operators should identify the UICCs used for IoT Services from traditional
UICCs used to provide traditional services and, if required by the IoT Service
Provider, segregate these appropriately.
o If the UICCs used for IoT Services are segregated from the UICCs used for
traditional handsets then this provides a basis for more secure and
efficient management of the associated subscriptions by the Network
Operator than might otherwise be the case. For example, a Network
Operator might consider using a separate HLR/HSS for Endpoint devices
which have extended lifetime and is better configured to support these
UICCs for a very long period of time (i.e. many years).
5.1.1 UICC Supply and Management
5.1.1.1 Remote management of the UICC (Over-The-Air, OTA)

IoT Endpoint devices are not physically accessible in some scenarios. To be able to perform
changes to the UICC remotely, UICC OTA management should be supported by the
Network Operator. The UICC OTA security mechanisms should follow the latest ETSI [1] [2]
and 3GPP [3] specifications and use the most appropriate level of security for the IoT
Service.
IoT Endpoint devices should support the necessary APDU commands recognized by the
UICC to make sure that UICC OTA command execution will succeed.
5.1.1.2 Non-Removable UICC

The Network Operator should provide non-removable UICCs (i.e. Machine Form Factor) for
IoT Services where the service threat model suggests that the IoT Endpoint device may be
vulnerable to physical tampering. Additional security measures should be applied to be able
to detect and react to such a threat.
V1.1 Page 15 of 27
5.1.1.3 Remote Management of Embedded UICCs (eUICCs)

The Network Operator should provide secure remote management of non-removable UICCs
(i.e. eUICCs) for IoT Services which require Endpoint devices to be located in remote or
difficult to reach locations.
For example, for IoT Service Providers who need to manage a large number of eUICCs that
are embedded into Endpoint devices for which the IoT Service Provider is not the owner and
cannot easily access (e.g. a car).
Typically Operators use IoT Connectivity Management Platforms to monitor and control the
communication services offered to the IOT Devices by (e)UICCs.
The Network Operator should support the GSMAs Remote Provisioning Architecture for
Embedded UICC Technical Specification [7].
5.1.1.4 UICC-based Services

A Network Operator might provide an IoT Service Provider with UICC based services. This
makes it possible for the IoT Service Provider to use the UICC as a secure and tamper
resistant platform for their IoT Services. Such UICC-based services are usually developed in
JavaCardTM and are interoperable between all JavaCardTM compliant UICC cards. An
example of such an application for an IoT Endpoint device could be the monitoring and
reporting of the network quality. The tamper resistance feature provided by the UICC
platform is highly valuable for IoT Endpoint devices that can be physically accessed by
attackers. Leveraging the UICC as a common secure element for all stakeholders may also
make secure IoT Endpoint devices more cost effective.
The UICC may also be used for tamper-resistant storage of sensitive data for IoT Services,
including security keys controlled by the IoT Service Provider. ETSI TS 102 225 [1]
leverages on the Confidential Card Content Management feature of the Global Platform
Card Specification to enable IoT Service Providers to independently manage their own
security domain on a UICC.
An IoT Service Provider or Network Operator can ask the UICC Supplier to create such
security domains inside the UICC. The issuer of the UICC should ensure that it is protected
by proper security keys and the IoT Endpoint device can execute the necessary APDU
commands to access it.
Additionally the UICC could also be used to encrypt (using its securely stored keys) and
send sensitive content for IoT Services, or provide security services for Endpoint device
based applications via services such as the Open Mobile API [4].
5.1.1.5 Secure UICC Manufacturing and Provisioning

A Network Operator should source their UICCs from manufacturers whose manufacturing
and provisioning processes are accredited according to the GSMAs Security Accreditation
Scheme (SAS) [16].
V1.1 Page 16 of 27
5.2 Network Authentication and Encryption Algorithms

This section contains recommendations and best practices for network authentication and
link encryption for different wide area networks.
The Network Operator should implement network authentication algorithms that meet the
lifetime expectations of the IoT Service Providers Endpoint devices.
Network Operators provide several types of communication services that can be used by an
IoT Service, such as USSD, SMS and IP data connectivity. For the purpose of this document
only IP data connectivity is discussed since it is the most utilised form of communication
service used by IoT Services.
USSD and SMS are used by many existing IoT Services so it is worth highlighting that
USSD and SMS have limited security support capabilities in comparison to IP data
connectivity. In general, USSD and SMS traffic is not by default end to end
cryptographically protected by the Network Operator and cryptographic protection
mechanisms to ensure confidentiality and integrity are not available for SMS messages. IoT
Service Providers that use USSD or SMS for their communication need to be aware of the
vulnerabilities associated with USSD and SMS and, where possible, implement additional
encryption at the service layer.
5.2.1 Security of GSM/GPRS (2G) Systems

Network Operators who provide GSM/GPRS networks should:
Use a minimum of 128 bit A5/3 stream cipher to protect link between the IoT Endpoint
device and the base station. Network Operators should avoid A5/1 and A5/2 or use of
unencrypted links where possible.
Use the MILENAGE authentication algorithm. Network Operators should avoid
COMP128-1 and COMP128-2. Network Operators should consider support of the
TUAK authentication algorithm
Take appropriate measures to address and mitigate false base station attacks.
In GSM/GPRS systems the network is not authenticated by the Endpoint device, only the
device is authenticated by the network. End-to-end encryption at the service layer is
therefore recommended when using GSM/GPRS systems. Consideration must be given to
practical processing, Endpoint device limitations and network bandwidth constraints in
solutions provided as IoT Services.
In GSM/GPRS systems the GTP-tunnel between SGSN and GGSN which is created over
the GRX-network is not encrypted. The Network Operator should ensure the security of this
link by ensuring GRX-network is managed as a private network.
5.2.2 Security of UMTS (3G) Systems

UMTS networks allow for mutual authentication, where the Endpoint device is not only
authenticated by the network, but the network is also authenticated by the device.
Network Operators who provide UMTS networks shall support the MILENAGE authentication
and key generation algorithm. Network Operators should support the Kasumi confidentiality
and integrity encryption algorithms.
V1.1 Page 17 of 27
Network Operators should consider support of the TUAK authentication algorithm
5.2.3 Security of LTE (4G) Systems

Network Operators who provide LTE network shall support the MILENAGE authentication
algorithm. Network Operators should support the LTE EEA1, EEA2 or EEA3 encryption
algorithms.
Network Operators should consider support of the TUAK authentication algorithm.
Network Operators are advised to review the GSMA whitepaper Wireless Security in LTE
Networks [30].
5.2.4 Security of Low Power Wide Area Networks

Several Low Power Wide Area Network (LPWAN) technologies exist with most being
proprietary and often not in the public domain. Examples include LoRa, SigFox and
Weightless.
While LPWAN technologies were initially developed to be standalone many of these

technologies are now being considered by 3GPP for inclusion within the 3GPP standards.
As such, security guidelines related to Low Power Wide Area Networks are out of the scope
of this document. .
5.3 Security of Fixed Networks

Recommendations for default configuration of Wi-Fi networks where under the control of a
Network Operator or an IoT Service Provider include EAP-SIM [28] or EAP-AKA [27]
authentication and may rely on the UICC EAP framework of ETSI TS 102 310 [8].
5.4 Traffic Prioritisation

Network Operators can provide Quality of Service levels appropriate to the IoT Service being
provided.
5.5 Backhaul security

The 3GPP standards that specify GSM, UMTS and LTE do not mandate the use of
encrypted backhaul links. Moreover, RAN and backhaul sharing between different Network
Operators may introduce additional security vulnerabilities.
The Network Operator should implement backhaul encryption for GSM, UMTS and LTE
networks for both end user data and signalling plane data traffic.
5.6 Roaming
Network Operators can provide IoT Service Providers with an international mobile footprint
through use of roaming services.
Roaming networks can be vulnerable to security breaches due to the relative openness of
the SS7/Diameter interworking functions used to connect the home and roaming networks.
This is of particular relevance to IoT Services due to the potentially high proportion of IoT
Endpoint devices that will reside on roaming networks. There are a few reasons for the high
V1.1 Page 18 of 27
percentage of roaming Endpoint devices. Firstly, many Endpoint devices are manufactured
in one location and distributed globally. Therefore in many cases replacing a UICC is not
practical or not possible in the case of embedded UICC. Secondly, in many cases the
roaming status is preferable over local connectivity, due to the potential multiple coverage by
several roaming networks. The formation of global alliances with a global UICCs and
dedicated IoT roaming agreements facilitate the permanent roaming situation where allowed
by local legislation.
Network Operators should consider how to protect their HLRs and VLRs against Denial of
Service attacks (including unintentional DoS attacks), requests from unauthorised sources
and exploitation of steering of roaming services.
The roaming is facilitated by the inter-Network Operator signalling protocols that are
exchanged between the main core mobile network entities:
1. Between the VLR or the SGSN in the roaming (visited) network and the HLR at the
home network the MAP (Mobile Application Part) protocol (for CDMA networks,
IS41 is similar to MAP).
2. Between the MME in the LTE roaming network and the HSS at the home LTE
network the Diameter (certain variants such as S6a) protocol.
3. Between the SGSN/S-GW in the visited network and GGSN/P-GW at the home
network the roaming data transfer using GTP (GPRS Tunnelling Protocol).
This section will concentrate on roaming security issues related to IoT Services. General
roaming security issues are covered by the GSMA FASG (Fraud And Security Group) and its
sub-groups. Hence, issues such as double registration in roaming, received from two
different VLRs located in different countries a classical roaming fraud scenario is out of
the scope of this document.
5.6.1 Roaming signalling storms/attacks

IoT has additional security requirements from the mobile network, due to the different nature
of the Endpoint devices and the potential high level of service criticality. While serving a
large number of Endpoint devices, the mobile network is exposed to signalling storms. An
intentionally malicious Denial of Service attack is only one reason for such storms. A power
failure, natural disaster or coverage problem in a certain area of a serving mobile network
can be common in many countries and therefore cause such issues. All roaming smart
meters and other Endpoint devices located in that area will attempt to roam to another
roaming network, simultaneously. Such a scenario creates a signalling storm and imposes a
severe risk on the home HLR/HSS. 3GPP TS 23.122 [9] defines an Extended Access
Barring (EAB) service to address such scenarios: Network Operators can restrict network
access to the Endpoint devices configured for EAB, in addition to common and domain-
specific access control mechanisms. EAB configuration can be performed in the UICC or in
the Endpoint device itself. Network security gateways should be configured to sinkhole
intentional Denial of Service attacks.
There may also be a need for the home Network Operator (together with the IoT Service
Provider) to distinguish between low priority Endpoint devices, and critical Endpoint devices.
For example, it may be necessary for healthcare devices to continue to maintain service
under signalling storms and service denial attacks. There may be a need for Network to
V1.1 Page 19 of 27
reject the registration of low priority roaming Endpoint devices under signalling storm
conditions, but to allow high priority Endpoint devices to register. The reject mechanism
implemented may be accompanied with a back-off timer, in order to assist the Endpoint
device in registration re-attempt, after the signalling storm.
The general recommendation would be for Network Operators to screen all roaming
messages received from home networks/roaming partners. In addition to blocking messages
from unauthorized/faked home networks/roaming partners, there is a need to filter the
messages according to the Endpoint device priority. Under signalling storm/denial of service
attacks, there is a need to either allow messages from high priority/critical Endpoint devices,
or reject messages from non-critical Endpoint devices. Reject methods are required in order
to postpone the registration attempts and other activities for a certain period.
5.6.2 Security-based Steering of Roaming (SoR)

Another security use case that can be carried out by a Network Operator is Steering of
Roaming (SoR) of IoT Endpoint devices for security purposes. Rejecting an Update Location
without a back-off timer causes the Endpoint device to re-try, and finally to attempt
registration from a different roaming (visited) network. Another method for SoR is via OTA,
using UICC roaming preferred lists and other parameters stored on the UICC. The UICCs
OTA update capabilities enables the home network to update the preferred roaming lists,
which determine the priority of the networks during the selection process of a roaming
network. The home network can also refresh the Endpoint device memory with the new list
and cause the Endpoint device to search for a new network instantly.
In case a security risk is detected in a specific visited network, the home network may decide
to transfer its outbound roaming Endpoint devices to another visited network, using the SoR
mechanism. Such an active transfer of Endpoint devices can be made upon the next
registration attempt of the Endpoint device, or ad-hoc using the SIM OTA services. A
security risk related to a specific visited network can be detected if a problem is reported by
a relatively high number of Endpoint devices roaming on that network, or information
received by other inputs.
5.6.3 Data Roaming Denial of Service

Denial of Service attacks are not limited to the mobility signalling space, and data roaming is
also a potential field for signalling storms. As of today, most of the roaming data is routed
from the visited network SGSN (S-GW in case of LTE) to the home network GGSN (P-GW
for LTE).The case of LBO (Local Breakout), where the data is routed from the visited
network directly to the internet is rarely implemented. The situation in the future might
change, due to regulations, such as the EU regulation that enabled the LBO service since
July 2014, LTE and especially VoLTE (Voice over LTE), where voice calls made in the
roaming network may be handled by the domestic P-GW (such as the case today with
regular circuit-switch voice calls made in a visited network).
Signalling storms may happen when the home GGSN/P-GW is flooded with requests for new
data sessions. The GPRS protocol creates a secured tunnel between the Endpoint device
and the GGSN, and a request for a new session (Create-PDP-Context) results in setting up
a tunnel, and allocation of an IP address to the Endpoint device. When IoT Endpoint devices
do not behave in a personalised manner, they can generate bursts of requests for new data
V1.1 Page 20 of 27
sessions as noted before. Denial of Service attacks can be generated by a relatively small
number of Endpoint devices, creating multiple requests for new data sessions in parallel.
The GGSN/P-GW servers are limited in their capacity and should be protected from such
storms.
To prevent signalling storms Network Operators may, based on a security policy, prevent
certain devices from connecting to their network by changing the communication profile of
the affected devices or by enacting security policies within the networks packet core.
Critical Endpoint devices should receive a service also under denial of service attacks, while
the requests of lower priority Endpoint devices are postponed for a certain delay period.
5.7 Endpoint and Gateway Device Management

It should be noted that the hardware and software security measures, including local
configuration management consoles for Endpoint devices and Gateway devices are beyond
the scope of this document. This section covers network related aspects. See GSMA
document CLP.11 IoT Security Guidelines Overview [11] for Endpoint device related
security guidelines.
5.7.1 Endpoint Device Management

Network Operators can offer IoT Service Providers with basic capabilities to securely
configure and manage Endpoint devices and subscriptions, adopting some of the principles
and technologies developed for traditional mobile device management. IoT Endpoint
devices that use a UICC to register and connect to a cellular network can be managed using
the connectivity management platforms, device management platforms and UICC
management platforms that exist today.
On top of this basic Endpoint device management capability more complex and specific
Endpoint Device management functionality can be provided by the IoT Service Platform.
An example of a typical Endpoint device management architecture is shown below and is

taken from the ETSI M2M communication principles [19].
V1.1 Page 21 of 27
Figure 3 - ETSI High Level Architecture for M2M Device Management
The blue blocks indicate what is traditionally managed by the Network Operators existing
device management platforms and the red blocks indicate the service component that are
managed by the IoT Service Platform.
Network operators can undertake some of the device management functions indicated in red
at the request of the IoT Service Provider.
5.7.2 Management of Gateway Devices

The use of Gateway devices potentially introduces one more level of device management
complexity to the IoT Service Provider. In some cases the IoT Gateway device may be a
UICC based device which connects to a cellular network, in some other cases fixed lines are
used.
The Gateway should be a managed object, in order for it to be monitored and updated with
new firmware or software should the need arise. Protocols for providing secure firmware and
software updates and secure software and systems integration mechanisms should be used
to secure the interconnection of the Gateway to the network backbone.
Network Operators can provide and manage secure Gateways on behalf of the IoT Service
Provider which allow Endpoint devices to securely connect in a way that best integrates with
the Network Operators wide area network security mechanisms.
Gateways that connect using fixed network connectivity can be managed remotely using the
Broadband Forum TR-069 Customer Premises Equipment (CPE) Wide Area Network (WAN)
Management Protocol [20].
Gateways that connect using cellular network connectivity can be managed remotely using
the OMA Device Management (DM) and Firmware Update Management Object (FUMO)
protocols [5] [6].
V1.1 Page 22 of 27
5.7.3 IoT Endpoint Device Blacklisting

Network Operators should implement IoT Endpoint device blacklisting and connection to the
GSMA Central Equipment Identity Register (CEIR) database. The CEIR is a central
database, administered by the GSMA, containing IMEIs associated with lost and stolen
Endpoint devices and devices that should not be granted network access. Once an IMEI is
entered into the CEIR the Endpoint device containing the IMEI will be blacklisted by all
Network Operators who take that data and implement local blacklisting based on their use of
equipment identity registers (EIRs).
Network Operators may also implement localised device greylisting to allow the temporary
suspension of suspect devices whilst the Network Operator investigates the nature of such
devices prior to any blacklisting. It should be noted that for critical services such as
healthcare, blocking an IMEI may not be desirable or possible. It is important that the details
of connected Endpoint devices should be clearly understood by Network Operators in so far
that the true application (or host) of an Endpoint device can be discerned. Endpoint devices
that leverage the IMEI issued to a communications module vendor should support Device
Host Identify Reporting which is a capability that enables the Endpoint device to report host
information to the Network Operator. Device Host Identify Reporting is described in the
GSMAs Connection Efficiency Guidelines [17].
5.8 Other Security Related Services
5.8.1 Cloud Services / Data Management

Network Operators can supply customers with hosted cloud IoT Service Platforms for
implementing IoT Services and also provide services for storing and managing the data
produced by such services.
Network Operators can supply either a private cloud or a shared cloud infrastructure
depending upon the requirements of the IoT Service Provider.
5.8.2 Analytics-based Security

Network Operators can provide data analytics and deep packet inspection services to
identify threats and anomalies in the data generated by IoT Services. An example could be
that a Network Operator could periodically perform deep packet inspection for specific
strings like social security numbers and GPS coordinates that might suggest that such
information is not protected properly and alert the IoT Service Provider responsible that
information could be leaking.
This is advantageous for IoT because Lightweight Endpoint devices and services cannot
provide this functionality themselves. Network Operators can provide IoT Service Providers
with visibility of the security status, identified threats and attacks as well as an overall
security health check. These introspection services are vital to ensure that threats are not
infiltrated inside the pipe, particularly where data services are encrypted. Services provided
include:
Use of anomaly detection and machine learning to spot problems.

Build intrusion protection systems into real-time Endpoint device diagnostics.
Provide dashboard for visualising and easily identifying anomalies.
V1.1 Page 23 of 27
Provide automated means for flagging and blocking suspicious connections.

Provide threat analysis of cloud based services.
5.8.3 Secure Network Management

Network Operators can provide networks that are securely managed and maintained.
Backup channels in case of physical or logical link failure

Identify link failure as evidence of potential security breach
Implement roaming policies impacting security and integrity
UICC/SIM Management
Management of secure information
Membership of CERTs and participation in threat information sharing to mitigate and
prevent future attacks.
Protection against Denial of Service attacks
Carry out periodic security scans / vulnerability assessments
Management and handling of network security related regulatory requirements
Restrict communications options to the strict minimum required for a given IoT
Service.
5.8.4 Secure IoT Connectivity Management Platform

Network Operators are increasingly making use of dedicated core network and OSS
infrastructure to manage IoT subscriptions and price plans in an efficient and scalable
manner. Access to such infrastructure is often exposed to the operators business customer
(i.e. an IoT Service Provider) so they can self-manage their subscriptions (that would include
activation of the service, suspension, etcindividually or in bulk).
The service platform guidelines offered in CLP 12 IoT Security Guidelines for IoT Service
Ecosystem [26] offers valuable guidance that can benefit the Network Operator who support
IoT Connectivity Management Platforms. These guidelines contain the following
recommendations:
Network Operators should make sure access to their IoT Connectivity Management
Platforms web portal, which could be Network Operator or Cloud hosted, uses best
in class encryption as per the most recently published industry guidance from
organisations such as NIST [24] and ECRYPT2 [25].
Network Operators should make sure access to their IoT Connectivity Management
Platforms web portal makes use of standard best practice procedures for password
creation, updating and resetting.
5.8.5 Certificate Management

Network Operators can provide X.509 certificate management services.
5.8.6 Multi Factor Authentication

Multi factor authentication services typically require a user to authenticate themselves using
an electronic token in addition to a username and password. As such, multi factor
authentication can provide additional protection against access to IoT Services from
unauthorized users.
V1.1 Page 24 of 27
The GSMAs Mobile Connect initiative [12], together with OpenID Connect [21], FIDO [22]
and ETSI MSS [23] are examples of multi factor authentication enablers that can enable an
IoT Service Provider to obtain additional authentication and information from their end users.
The end user in this context being a human that can provide information to an IoT Service
Platform to provide different levels of assurance examples include entering a PIN and
providing a biometric signature.
Whilst most multi factor authentication solutions are currently used to enable traditional
smartphone services such technologies could be applied to IoT Services that require the
assurance of human authorisation for certain tasks such as performing a network attach
operation, software update or hard reset.
For example, using multi factor authentication, a mobile identity could be used in addition to
a Gateway device inside a connected car. In this use case the multi factor authentication
infrastructure could act as an additional authorization layer for the cars occupants to gain
access to infotainment and payment services provided within the car.
V1.1 Page 25 of 27
Annex A Document Management
A.1 Document History

Authority Company
GSMA
1.1 17-Nov-2016 References to GSMA IoT Security PSMC

Ian Smith
Assessment scheme added.
GSMA
Minor Editorial corrections.
A.2 Other Information

Type Description
V1.1 Page 26 of 27

GSMA IoT Security Guidelines (English)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GSMA IoT Security Guidelines (English)

Uploaded by

Copyright:

Available Formats

GSM Association Non-confidential

Official Document CLP.11 - IoT Security Guidelines Overview Document

IoT Security Guidelines Overview Document

This is a Non-binding Permanent Reference Document of the GSMA

Security Classification: Non-confidential

9.4 The Security Model 29

1.1 Executive Overview

Whilst many service providers, such as those in automotive, healthcare, consumer

1.2 GSMA IoT Security Guideline Document Set

CLP.17 GSMA IoT Security Self-Assessment Checklist

- GSMA IoT Security Guidelines Document Structure

1.2.1 GSMA IoT Security Assessment Checklist

Assessment declarations can be made by submitting a completed declaration to the GSMA.

1.3 Document Purpose

1.4 Intended Audience

Ref Doc Number Title

2 The Challenges Created by the Internet of Things

Availability: Ensuring constant connectivity between Endpoints and their respective

2.1 The Availability Challenge

2.2 The Identity Challenge

2.3 The Privacy Challenge

Is the identity of an Endpoint exposed to unauthorized users?

Is data emanating from an Endpoint or IoT Service indicative of or directly associated

2.4 The Security Challenge

3 The Mobile Solution

3.1 Addressing the Challenge of Availability

3.2 Addressing the Challenge of Identity

An excellent advancement to this already security hardened technology is that new

3.3 Addressing the Challenge of Privacy and Security

4 The IoT Model

Example IoT Model

4.1 Service Ecosystem

4.2 Endpoint Ecosystem

automotive telematics systems, sensor-driven industrial control systems, and more.

What assets (digital or physical) need to be protected?

5.2 Risk Model References

National Institute of Standards and Technology (NIST)s Risk Management

Who is collecting, sharing and using individuals data?

7 Using This Guide Effectively

Evaluate the technical model

7.1 Evaluating the Technical Model

What components are used to build the product or service?

7.2 Review the Current Security Model

7.3 Review and Evaluate Recommendations

7.4 Implementation and Review

7.5 Ongoing Lifecycle

Requirements change over time. Cryptographic algorithms become dated or deprecated.

8 Example Wearable Heart Rate Monitor

8.1 The Endpoint Overview

Simple HRM and Primary Components

8.2 The Service Overview

Flow of Data to Simple Back End Service

8.3 The Use Case

8.4 The Security Model

There is no security front-end diminishing the effects of a Denial of Service attack

8.5 The Result

Resultant Service Ecosystem

9 Example Personal Drone

9.1 The Endpoint Overview

A Drone and its Primary Components

9.2 The Service Overview

Flow of Data to Back End Services

9.3 The Use Case