Getting started with IoT security · IoT devices. The IoT Security Foundation has prepared an IoT Security Compliance Framework to provide pragmatic guidance to businesses developing

1 | G e t t i n g s t a r t e d w i t h I o T s e c u r i t y

Getting started

with IoT security

White paper written by:

Chris Jones Senior Applications Engineer

Secure Thingz


Contents Introduction ........................................................................................................................................... 3

Security overview.................................................................................................................................. 3

IoT codes of practice ............................................................................................................................... 5

IoT product architecture ...................................................................................................................... 6

Security threat analysis ....................................................................................................................... 8

Security implementation plan ........................................................................................................... 10

Development process flow ............................................................................................................... 10

Identity, Root of Trust, Chain of Trust .......................................................................................... 12

Provisioning..................................................................................................................................... 14

Software development................................................................................................................... 15

Mastering ......................................................................................................................................... 16

Secure deployment ........................................................................................................................ 17

Implementation................................................................................................................................... 19

Concluding remarks ........................................................................................................................... 21

Appendix A: Code of practice for consumer IoT security ..................................................................... 23

Appendix B: References to webinars, user guides, application notes, and related documents .......... 26


Introduction The digital transformation agenda is a high priority for most senior management and

product development teams in almost every industry vertical. The expected explosion in the

number of connected devices that will be needed to satisfy this demand also exposes those

devices to potential security breaches.

This white paper is targeted at developers who are new to security and wish to understand

how they can implement security into their internet of things (IoT) product design.

Specifically, it outlines the processes of developing IoT products that include a secure

device such as a secure element (SE) or a secure microcontroller (MCU). In order to

illustrate the ‘how,’ this white paper references Secure Thingz products and workflow

processes. Hence, there are no references to specific secure microcontroller or secure

element part numbers.

In the appendices, several references are included to webinar materials, user guides and

application notes, and various industry developed security-related documents.

Security overview Security is critical to the success of the internet of things (IoT). Product security is

fundamental in the development and maintenance of connected systems in both industrial

and consumer markets.

The process needs to start with a security policy that provides the basis for enforcement

and adherence to appropriate cyber security legislations that apply to the IoT system.

Operational and infrastructure security rely on devices that are inherently secure. For this to

happen, the foundation for robust and reliable IoT infrastructures depends on secure device

manufacturing and device security.

Figure 1: Security Pyramid which is built on Secure Thingz’s technology


This is why security must be considered early in the marketing and engineering development

cycles of devices, software and services.

This white paper intends to assist developers in all aspects of security during the

development of secure device-based IoT products. Figure 2 provides a guide through the

process of developing a secure IoT product.

Figure 2: The IoT product development process


IoT codes of practice Government agencies are increasingly becoming aware of the threat posed by non-secure

IoT devices. The IoT Security Foundation has prepared an IoT Security Compliance

Framework to provide pragmatic guidance to businesses developing devices and services

that have network connectivity to enhance their functionality.

Security best practices require choices in design, features, implementation, testing,

configuration and maintenance. There are a great many considerations including protocols,

encryption, technology, software, application programming interfaces (APIs), platforms and

more.

Examples of government studies include:

UK Government (Dept. for Digital, Culture, Media & Sport):

Secure by Design: Improving the cyber security of consumer Internet of Things Report

European Union Agency for Network and Information Security (ENISA)

Baseline Security Recommendations for IoT in the context of Critical Information

Infrastructures

US Department of Commerce (National Institute of Standards & Technology)

Interagency Report on Status of International Cybersecurity Standardization for the Internet

of Things (IoT)

A Code of Practice (see Appendix A) has been developed based on the findings of some of

these reports, which are also highlighted in a Secure Thingz webinar available on its web

site, entitled, ‘Does your IoT device meet the legislation requirements?’

Security requirements should be added to IoT product requirements prior to development

start to ensure regulatory requirements are met and the IoT product is secure throughout its

entire life cycle (design, production and support).

Let us take a typical IoT product and examine how aspects of the best practices should be

implemented:

A household thermostat is a good example of a modern IoT device that is connected to the

internet and can be controlled from a remote entity. Security in this instance is extremely

important as the thermostat has access to a private network and the device has control over

a potentially dangerous heating system.

Clearly, secure communication is important for this type of device (Appendix A:5). In order to

implement this, the device must be designed such that it has an identity. A unique identity

that can be verified by cryptographic means ensures that the thermostat can be

authenticated and can communicate with other systems in a secure manner. Additional

software functions can build on the unique identity and provide services such as mutual

authentication which is required when using any cloud-based services. See section 6.1 for

details on the creation of identity in an IoT product.

A device such as a thermostat is required to be in service for many years. It is unlikely that

no vulnerabilities, in the software that is running on the thermostat, will be found during the

lifecycle of the device. It is, therefore, important that such a device includes the capability to

allow software updates (Appendix A:3) over the private network. Software update services


require that the device includes a Root of Trust in order to authenticate any software update

and ensure that it has originated from a trusted entity. An update policy is also required in

order to protect the device against software rollback attacks, which can occur if older

software versions contain a security vulnerability. See section 6.5 for details on the

implementation of a software update mechanism.

IoT product architecture The architecture of an IoT product is dependent on the requirements of the local functions

that need to be processed and the type of connectivity required. Local functions can be

simple, such as sensor reading, alarm sounding, LED illumination, motor control, etc. These

functions are commonly implemented using a microcontroller. However, not all

microcontrollers have security integrated into their design.

Figure 3: Examples of IoT hardware architectures

Here is an explanation of each of these different architectures:


Multi-core secure MCUs

These are high-end processors that are usually associated with a dedicated software tool to

allow easy integration with cloud-based applications. The devices are closely associated

with software services for IoT which includes large-scale device management, data

analytics, device monitoring and machine learning. A good example of such a product is the

Microsoft Sphere/Azure system.

Fully integrated secure MCU

This architecture is arguably the most common and cost-effective solution. This

architectural type is also fast growing as semiconductor manufacturers are racing to add

more security features to their standard MCUs to take advantage of the growth of IoT. MCUs

with security features are available from all the top semiconductor manufacturers such as

Renesas, STMicroelectronics and Microchip, to name a few.

MCU plus cryptographic unit

This type of architecture has generally been used as the interim solution prior to the

availability of dedicated secure MCUs. In this case, the standard MCU communicates with

the dedicated cryptographic unit (CU) via an interface such as SPI or I²C. Examples of

available CUs are the Infineon Optiga™ Trust series, Maxim’s DeepCover family and

Microchip’s Crypto Authentication devices. Services such as HASHing, asymmetric key

generation and more advanced features such as signing are available to the standard MCU

via the communication interface. The exposed serial interface is often secured using the

dedicated public key available from the CU. The CUs often include extensive hardware

security features which are not currently available in many secure MCU devices, giving this

architectural type an advantage over the fully integrated solution.

Secure element

These devices have been available for some time and most engineers are aware of them in

mobile phones and smart cards. Secure elements (SE) have hardware security measures

integrated into the semiconductor devices providing features such as tamper detection,

internal metal shields, encrypted memories and fully secure production test methodologies.

SEs come in different form factors such as Universal Integrated Circuit Cards (UICCs) and

microSDs, which are removable. Embedded SEs (eSEs) and embedded UICCs (eUICCs) are

directly bonded to a product PCB.

-------

Connectivity requirements also influence the architecture. Communication protocols such

as DTLS can be supported by some SEs allowing offloading of the MCU software. Some

example connectivity architectures are shown in Figure 4.


Figure 4: Examples of IoT product connectivity

Security threat analysis Once the IoT product architecture has been considered with regards to connectivity and

hardware, it is important to then consider the possible threats to the IoT product. A threat

analysis is part of the development process and considers the attack vectors that may be

available to bad actors who are intent on intellectual property theft. The threat analysis and

remaining development process will assist with the choice of hardware elements to be used

in the design. Also, it is important to understand the support from tools and infrastructure

available which will allow the IoT product to be securely manufactured.

Some examples of the types of attacks that could be expected in an IoT environment are

listed below:

Location

o Is the IoT product easily accessible? e.g. top of a lamppost,

underground, etc.

Access (physical)

o Is the IoT product circuit board exposed? e.g. easy to probe, poorly

mounted, etc.

Access (electrical)

o Does the IoT product have multiple communications ports? e.g. debug

port, UART, Ethernet, etc.


Figure 5 demonstrates what are commonly referred to as “trust anchors.” The bottom (or 1)

layer is the most fundamental level and must be protected at all costs because it is the

fundamental basis for trust on all the higher layers. This layer provides secure boot services,

including identity services, recovery management, and remediation update and patching.

Once you get above the 2-layer, the attack surface increases dramatically because there are

so many ways that a malicious actor can attempt to compromise the system. The key is to

have a really strong 1-layer and 2-layer to secure your IP because the attack surface is small

and because it’s the basis of security for the entire system.

Figure 5: Visualizing attack vectors

By thinking about the attack surfaces of the IoT product, simple measures can be

implemented during the development that can mitigate any attempts to attack the IoT

product once in the field. A small change (and cost) at this early stage can prevent the much

larger costs that the theft of intellectual property can incur if bad actors exploit insecure IoT

products.

The ‘STRIDE’ model

A guide developed at Microsoft and widely used for threat analysis uses the acronym

‘STRIDE’ to describe six categories of threats to software. Using STRIDE, it’s possible to

pose detailed questions about the kinds of attacks that could be targeted at software

running on an IoT product. The aim is to determine the types of attacks that could be

possible at each vulnerable point in the software, then to create a scenario for each possible

attack.

In essence, STRIDE is derived from:

Spoofing: using someone else’s credentials to gain access to otherwise inaccessible

assets. A process mounts a spoofing attack by passing forged or stolen credentials.


Tampering: is changing data to mount an attack. In this situation, a malicious user

could alter the files, thus breaching system security.

Repudiation: occurs when a user denies performing an action, but the target of the

action has no way to prove otherwise.

Information disclosure: the disclosure of information to a user who does not have

permission to see it.

Denial of service: attacks threaten the ability of valid users to access resources. The

resources could be disk space, network connections, or a physical device.

Elevation of privilege: an attack that can occur if an unprivileged user gains privileged

status.

Security implementation plan Once security requirements are defined and security threats have been identified, it is

important that the IoT product developer creates a security implementation plan that will

identify the specific critical security credentials for the IoT product as well as other critical

security items like the development process, manufacturing process and life cycle process

(for example, software updates).

Development process flow There are three critical areas that must be understood prior to embarking on the

development of a secure IoT product:

1. What are the trust anchors during software development?

How is the product identity formed?

How is the Root of Trust established?

How are certificates created?

2. How is a secure manufacturing / programming process to be realised?

Security compromised during provisioning?

Keys leaked?

Product identities cloned?

Software IP theft?

3. How will security continue to be enforced after the product has been

manufactured?

Secure software updates?

System compromised?

Customer data protected?


The following discussion explores how these considerations translate to the development

process flow for implementing IoT security.

Figure 6: IoT product development flow

The key stages of the product development flow are identity, provisioning, mastering and

deployment.

Identity – with a unique strong device identity, an IoT product can be authenticated when it

tries to connect and comes online, and it can ensure secure and encrypted communication

between other devices, services and users. The identity (device private key, device

certificate, silicon ID etc) is the critical element in ensuring that a Public Key Infrastructure

(PKI) can be implemented.

Provisioning – there are many definitions for this term dependent on the context. In the

context of a SE or secure MCU, the term "provisioning" means to program a device with the

identity/root of trust anchors so that it can be handed-off to an end user or application, for a

specific use in a functional manner. More specifically, for an IoT product, the device is linked

to a certificate and any boot manager firmware is programmed into secure memory areas.

Mastering – this stage is carried out once the development of the application is complete.

The final software image is released, then packaged (signed and encrypted), ready to be

sent to a secure programming facility. The output of this process is a mastered package

which is typically comprises an encrypted/signed software image and a separate update

protection package which is signed by the OEM private key. The files either form part of the

initial product or as part of an in-the-field post-production update. This process is carried out

at a secure facility.

Deployment – this is the process whereby the mastered software package is delivered to the

IoT product secure device. In the case of production, the mastered package is securely

delivered to the programmer which injects the software into the IoT device. In the case of a

secure update, the mastered software package is delivered directly to the IoT device that is

in the field (e.g. over-the-air or OTA update).


More details on identity, provisioning, software development, mastering and secure

deployment follow.

Identity, Root of Trust, Chain of Trust Typically, at the heart of an IoT product is a small and energy-efficient MCU. A secure

foundation starts with either a secure MCU with a “root of trust” (RoT) or an MCU with an

adjoined SE (where the SE incorporates the RoT). The RoT is the baseline for a device’s trust,

and different vendors take different approaches to implementation of a RoT. The most

effective solution is a unique device key pair combined with a certificate structure from the

OEM that forms the RoT in the device, coupled with security capabilities that protect,

authenticate and attest to the certificates. In addition, this certificate structure must be

placed in the device very early in its life and in a highly secure fashion.

Root of Trust

For IoT product design, the RoT is an immutable boot process within the system based on

unique identifiers (Unique ID), cryptographic keys and on-chip memory, to protect the device

from being compromised at the most fundamental level. The chain of trust extends the RoT

into subsequent applications and use cases. The key considerations when selecting an MCU

include identifying if the manufacturer has included these functions within the device:

a. A secure chain of trust (CoT). This must be an immutable boot path that cannot be

interrupted by the debug/JTAG interface.

b. The ability to ensure a secure boot process that authenticates the software image

before it is executed.

c. The ability to program and lock a section of boot flash memory (~64KB) so that it is

immutable (i.e. MCU boot manager cannot be erased/reprogrammed).

d. In addition, the MCU can increase security by supporting a secure key storage facility

that prevents the access to the keys from unauthorized users (i.e. The security data

storage cannot be accessed by the main application).

The following additional features can be added to a secure MCU to boost the security of an

IoT product, and we’ve graded them out of five stars to indicate which are the most secure

features that can be added.

Integrated hardware cryptographic accelerator

There are many different types of cryptographic accelerators available that are integrated

into secure MCUs. An accelerator includes basic cryptographic functions that are primarily

designed to increase the speed of the encryption/decryption processes. This

function/peripheral is used to enhance the performance of the system when using

cryptographic functions. Typical features for these accelerators include:

Advanced Encryption System (AES) with multiple modes of operation

True Random Number Generator (TRNG)

HASH engine (MD5, SHA-1, SHA-2)


HMAC (HASH-based Message Authentication Code)

Direct Memory Access support

Typically, the accelerator does not include key storage or obfuscation features that are the

domain of the secure enclave/island.

Secure Enclave/Island

There are many terms for this particular security peripheral type, but ostensibly it refers to a

separate MCU or engine that is isolated from the main processor core and peripherals.

Access to this peripheral is typically via a secure mailbox system. All cryptographic keys

required for the system to operate are generated by the secure enclave/island and held

within it. Keys cannot be read out from the secure enclave/island or accessed directly in any

way by the main application. Key functions such as signing, verification, encryption and

decryption are carried out by the secure enclave/island without exposing plain text key

information.

ROM-based 1st stage bootloader

It is preferred that the secure MCU includes a ROM-based bootloader that configures the

system (e.g. clocks, peripherals) and then checks the integrity of either the application or 2nd

level bootloader before executing firmware that is programmed into the Flash region. The

ROM based bootloader can include secure access functions that allow secure updating

(encrypted) as part of a secure provisioning process (factory or secure programming

facility).

Bare-metal cryptographic key pair

Most bare-metal secure MCUs that leave the factory of the semiconductor manufacturer do

not include a cryptographic key pair that can be used for encrypted communications during

the initial provisioning stage of the device. Those secure MCUs that do include this

important feature are recommended. The embedded keys (plus associated embedded

firmware) allow any communication between the programmer and the device (via JTAG or

debugger port) to be encrypted, thus ensuring that any data passing over the interface is

secure. This allows secure provisioning/programming of any required secure boot manager

and associated data.

Silicon ID

Ideally, the secure MCU should leave the semiconductor manufacturer’s factory with a

unique identifier (ID) or silicon identifier. This unique ID can take many forms, an example

being the Universally Unique Identifier standard (UUID) which takes the form of a 128-bit

number. This number can be used when generating a device certificate for the IoT product.

The unique ID can be used to cryptographically tie the certificate to the ID of the device thus

enhancing the identity of the IoT product.


Hardware lockdown

This feature must be used with caution as ideally it is irreversible. The ability to lock down

the secure MCU so that there is no possible access to the internals of the device via the

JTAG or debug port enhances the security of the device considerably. Ideally, the lockdown

feature would include access control of specific areas of memory ensuring that they cannot

be erased or written to once the device has left the production facility. Any further access to

the device would only be under the control of the main application.

With the creation of a RoT using the features listed above, an environment should be

established to tightly control firmware (i.e. make sure it hasn’t changed, can’t be stolen and

can’t be over-produced). This must be able to operate securely in any manufacturing

environment. With the right RoT, the end result is a trusted device that will operate as

intended and protect a company’s IP, starting from manufacture to secure updates in the

field.

Chain of Trust

Product developers who adopt a “zero/low trust” approach across the supply chain can

minimize vulnerabilities and IP loss or theft. This means continually authenticating and

individualising deliverables across the supply chain as far as possible – which involves

establishing a chain of trust across the entire product lifecycle. This includes through to the

end customer who will need a way to securely apply software updates for its product. A

typical supply chain of trust is shown in Figure 7.

Figure 7: Supply Chain of Trust

The chain of trust should start with silicon vendors (for the secure element or secure MCU)

and continue with programming solution providers and contract manufacturers all the way

through to the original equipment manufacturer (OEM), who develops the IoT products, and

even the end customer who needs to securely update the product in the field. The chain of

trust must be thought of as a process flow - any step in the process builds upon the security

of the previous step.

Provisioning This step in the workflow is critical to creating the RoT in an IoT product. It is the

programming step that programs the bare metal secure MCU or secure element with the


required certificates / keys / data and configuration that defines the IoT product and

prepares it for operation in the field (see Figure 8). The provisioning step can also include

the programming of the customer’s/OEM’s firmware (IP).

The configuration process during provisioning ensures that the secure device is locked and

that secrets within the device are only accessible by secure boot managers. The “locking”

mechanisms vary between semiconductor manufacturers. Some are via a non-recoverable

“fuse” and others may allow erasure of provisioning data to allow recovery of a device.

This step must be absolutely secure as provisioning generally takes place at programming

centres and contract manufacturing facilities which are outside of the control of the OEM.

The provisioning information contains secret keys and customer IP and a policy of “zero

trust” is imperative to ensure the supply chain of trust.

Figure 8: Provisioning process (bare metal to programmed RoT)

Software development This step in the workflow incorporates the software development of the actual application

that will be running on the microcontroller in the IoT product. There are many integrated

development tools (IDEs) available that support many microcontroller devices. These IDEs

provide important functions such as content assist source code editors, compilers, code

analysis and debuggers.

Examples of such IDEs are Eclipse and Keil. However, most of the currently available IDEs do

not support many of the security functions highlighted in this white paper. One approach is

the IAR Embedded Trust/C-Trust solution, an add-on product to the IAR Embedded

Workbench produced by IAR Systems. It is a security development environment (SDE) that

integrates security into the workflow by:

Defining identity

Simplifying security development


Streamlining secure manufacturing

Enabling the management of devices across their life cycles

The Embedded Trust product enables a security engineer to set up the secure development

process, while the C-Trust product is a client application used primarily by application

development engineers to apply the security settings created using Embedded Trust.

Figure 9: Features of Embedded Trust and C-Trust, available as an add-on product to the IAR

Embedded Workbench

Mastering Mastering ensure that products can be securely produced and updated in the field. It

involves processing of the software application image so it will be accepted by the end

device. Ideally, the target device (for the software application image) has been provisioned

(see Section 6.2) with a secure boot manager along with the OEM/customers’ secret keys.

This helps maintain a product’s unique identity and provides assurance that all software

loaded into the MCU has a known providence. Any firmware or software image that is to be

loaded into the MCU must go through a “mastering” process where the image is signed and

encrypted. Inhibiting intellectual property theft and undermining counterfeiting are the key

goals of the secure manufacturing process. To achieve secure manufacturing, it is therefore

fundamental to encrypt the application software as early as possible and only decrypt the

software in-situ in the device itself, securing as many touch points as possible.

Only the OEM/customer personnel developing the product software should be given access

to the mastering process. The mastering process itself accepts the application software

image and encrypts the image with a secure advanced encryption standard (AES) key, then

creates a mastered software package containing the AES key along with version info that is

signed with a unique cryptographic mastering key and encrypts the image with other product

specific device keys. The master signing key and other keys must be handled securely to

prevent third parties from having access to them, and it is optimal to incorporate a solution

that integrates a robust hardware security module (HSM).

The output of the mastering process (see Figure 10) is a pair of encrypted files which are

loaded into a secure manufacturing process. These secure files can only be decrypted and


verified by the secure boot manager that was provisioned with the corresponding master key

and product keys.

Figure 10: Mastering process

Secure deployment Ultimately, once the OEM/customer has completed the development and testing of their

application, it must be delivered to either:

a) a programming facility to allow high volume manufacturing of the IoT product, or

to

b) the IoT product that is deployed in the field and forms part of a secure software

update

It cannot be assumed that the transportation channel is secure and therefore a secure

means of delivery of the software application image must be utilised as part of the

deployment process. The following sections describe the methods used incorporating the

Secure Thingz “zero-trust” philosophy.

Production

This involves passing the output from the mastering process (encrypted image and UPF) to

the secure production facility for high volume manufacturing. Secure Thingz adopts a “zero-

trust” philosophy for this process by utilising a hardware security module (HSM). In order to

be able to transport the UPF and encrypted image over insecure channels, the certificate of

the target HSM (at the programming facility) should extract the public key of the HSM. The

public key of the HSM is then used to encrypt the UPF (see Figure 11). Both encrypted image

and encrypted UPF can now be delivered to the HSM over any transport medium. Only the

target HSM (integrated into the programmer) can unwrap the OEM/customer UPF and

encrypted image for use in programming the target device.


Figure 11: Delivery of mastering output to secure production facility

Software update

This step involves passing the output from the mastering process (encrypted image and

UPF) directly to an IoT product that is deployed in the field. In this case we are unable to use

an HSM public key to encrypt the UPF. As the delivery is direct to the target secure

microcontroller, we can utilise the secure microcontroller’s device certificate (see Figure 12)

that was provisioned into the device. The delivery channel/mechanism is entirely under the

control of the application software running on the IoT product. It is common for either a WiFi,

USB or Bluetooth communications channel to be used for software update delivery. Since

the UPF and software application image are both encrypted and can only be unwrapped by

the secure microcontroller within the IoT product, Secure Thingz “zero-trust” philosophy is

realized for the software update.


Figure 12: Delivery of mastering output to IoT product

Implementation So far, we’ve looked at the individual steps in the development flow for designing secure IoT

products. However, there are tools available to development engineers to simplify the entire

process, such as the Secure Thingz Embedded Trust/C-Trust security development

environment.

The key purpose of such environments is to ease the aspects of IoT security as described

throughout this white paper, namely:

Identity creation

Provisioning

Mastering

Secure deployment

The tools help leverage the secure hardware built into next-generation microcontrollers to

provide the low-level trust anchors and secure services needed for trustworthy IoT solutions,

and include:

Integrated identity and certificate management

Scalable secure boot manager

Secure deployment with integrated manufacturing mastering

Release management with versioning and update infrastructure

Such systems are ideally fully integrated within standard integrated development

environment (IDE) toolchains (see Figure 13), enabling OEMs to include security

development as part of their day-to-day workflow, while making sure their code is fast,

efficient and highly compact.


Figure 13: Security software development flow as part of an integrated development

environment

The steps that define the framework for the secure development environment are shown in

Figure 14.

Figure 14: Secure application development workflow

Expanding on the identity creation, provisioning, mastering and secure deployment that an

integrated tool might enable, here’s a short outline of the steps and how they can be

addressed.

Identity creation (security context)

This involves defining the identity of the target device (microcontroller) which forms the core

of the IoT product. This identity is created as part of the secure context definition which is

the security environment that will protect the IoT product application. The secure context

definition process includes specifying security properties like the public keys and

certificates, the secure boot manager that manages on the device an application update

process, and the device memory layout.

Provisioning

This process includes programming the identity, certificates, keys, and security lock bits into

the microcontroller. Also included in the process is the programming of the secure boot

manager. After this stage, the secure boot manager can no longer be changed and all

subsequent “application programming” for the processor must be delivered via the secure

process that uses the boot manager to ensure that the application code is signed and

encrypted correctly. Provisioning also creates an immutable secure boot path, meaning that

there is no other way to boot the secure device except by using the boot manager.


Mastering

This process generates a secure software update file. An integrated security development

environment would ideally create this file (for example in Motorola S-records format)

suitable for programming into a device with a provisioned secure boot manager. The image

should contain the OEM/customer encrypted application and an update header; hashed and

signed using a specified private mastering key, whose public part has been provisioned on

the device with the secure boot manager. Input to the mastering process is the security

context, which the software update file is uniquely tied to. It can therefore only be installed

on a device that has been provisioned with a secure boot manager generated with the same

security context. The process would use keys that were generated when the security context

was created.

Secure deployment

This process prepares the secure software update file, using the public key of the hardware

security module (HSM) or target device, to ensure secure delivery of the software application

to the target whether that be the IoT product or the secure programming facility. A security

development environment would simplify the preparation of the secure package ready for

delivery into a ‘production export’ function for secure deployment. This could then have the

capability for an OEM to select its chosen programming service provider such as one of the

following:

Arrow Electronics

EBV Elektronik

Avnet-Silica

Avnet

EPS Global

-----------

Concluding remarks Security for connected devices is more important than ever. The threats are real – incidents

of attacks, counterfeiting and cloning are growing, and governments are getting involved

with legislation and policies. The ramifications could break companies, if they are not

prepared.

Secure Thingz and its sister company IAR Systems share a vision securing intellectual

assets, accelerating trustworthy product delivery and making security a benefit instead of a

cost. For this, IoT security needs to be straightforward, scalable and sustainable, and

security must be integrated from inception, because adding security late in the development

process rarely works.

We hope this document helps developers not familiar with the many issues surrounding

security of IoT connected devices. This white paper, along with additional information

available from the Secure Thingz website will hopefully empower developers when faced

with the many complex technologies and processes required to design a secure IoT product.

-----------



Appendix A: Code of practice for consumer IoT security The UK’s Department for Digital, Culture, Media and Sport (DCMS), in conjunction with the

National Cyber Security Centre (NCSC), and with industry, consumer associations and

academia has developed ‘The Code of Practice’ which brings together, in thirteen outcome-

focused guidelines, what is widely considered good practice in IoT security.

The aim of the Code of Practice is to support all parties involved in the development,

manufacturing and retail of consumer IoT with a set of guidelines to ensure that products

are secure by design and to make it easier for people to stay secure in a digital world. It sets

out practical steps for IoT manufacturers and other industry stakeholders to improve the

security of consumer IoT products and associated services. Implementing its thirteen

guidelines will contribute to protecting consumers’ privacy and safety, whilst making it

easier for them to use their products securely. It will also mitigate against the threat of

Distributed Denial of Service (DDoS) attacks that are launched from poorly secured IoT

devices and services.

The guidelines bring together what is widely considered good practice in IoT security. They

are outcome-focused, rather than prescriptive, giving organisations the flexibility to innovate

and implement security solutions appropriate for their products.

The Code of Practice is not a silver bullet for solving all security challenges. Only by shifting

to a security mindset and investing in a secure development lifecycle can an organisation

succeed at creating secure IoT. Products and services should be designed with security in

mind, from product development through their entire lifecycle. Organisations should also

regularly assess cyber security risks relevant to their products and services and implement

appropriate measures to address these.

The supply chains of IoT products can be complex and international, often involving multiple

component manufacturers and service providers. The aim of the Code is to initiate and

facilitate positive security change throughout the entire supply chain.

A high-level summary of the guidelines is presented here. The full guidelines from the DCMS

can be obtained at https://www.gov.uk/government/publications/secure-by-design/code-of-

practice-for-consumer-iot-security from the UK Government’s web site.

1. No default passwords

All IoT device passwords shall be unique and not resettable to any universal factory default

value.

2. Implement a vulnerability disclosure policy

All companies that provide internet-connected devices and services shall provide a public

point of contact as part of a vulnerability disclosure policy in order that security researchers

and others are able to report issues. Disclosed vulnerabilities should be acted on in a timely

manner.

3. Keep software updated

Software components in internet-connected devices should be securely updateable.

Updates shall be timely and should not impact on the functioning of the device. An end-of-

life policy shall be published for end-point devices which explicitly states the minimum

length of time for which a device will receive software updates and the reasons for the

https://www.gov.uk/government/publications/secure-by-design/code-of-practice-for-consumer-iot-security



length of the support period. The need for each update should be made clear to consumers

and an update should be easy to implement. For constrained devices that cannot physically

be updated, the product should be isolatable and replaceable.

4. Securely store credentials and security-sensitive data

Any credentials shall be stored securely within services and on devices. Hard-coded

credentials in device software are not acceptable.

5. Communicate securely

Security-sensitive data, including any remote management and control, should be encrypted

in transit, appropriate to the properties of the technology and usage. All keys should be

managed securely.

6. Minimise exposed attack surfaces

All devices and services should operate on the ‘principle of least privilege’; unused ports

should be closed, hardware should not unnecessarily expose access, services should not be

available if they are not used and code should be minimised to the functionality necessary

for the service to operate. Software should run with appropriate privileges, taking account of

both security and functionality.

7. Ensure software integrity

Software on IoT devices should be verified using secure boot mechanisms. If an

unauthorised change is detected, the device should alert the consumer/administrator to an

issue and should not connect to wider networks than those necessary to perform the

alerting function.

8. Ensure that personal data is protected

Where devices and/or services process personal data, they shall do so in accordance with

applicable data protection law, such as the General Data Protection Regulation (GDPR) and

the Data Protection Act 2018. Device manufacturers and IoT service providers shall provide

consumers with clear and transparent information about how their data is being used, by

whom, and for what purposes, for each device and service. This also applies to any third

parties that may be involved (including advertisers). Where personal data is processed on

the basis of consumers’ consent, this shall be validly and lawfully obtained, with those

consumers being given the opportunity to withdraw it at any time.

9. Make systems resilient to outages

Resilience should be built in to IoT devices and services where required by their usage or by

other relying systems, taking into account the possibility of outages of data networks and

power. As far as reasonably possible, IoT services should remain operating and locally

functional in the case of a loss of network and should recover cleanly in the case of

restoration of a loss of power. Devices should be able to return to a network in a sensible

state and in an orderly fashion, rather than in a massive scale reconnect.

10. Monitor system telemetry data

If telemetry data is collected from IoT devices and services, such as usage and

measurement data, it should be monitored for security anomalies.


11. Make it easy for consumers to delete personal data

Devices and services should be configured such that personal data can easily be removed

from them when there is a transfer of ownership, when the consumer wishes to delete it

and/or when the consumer wishes to dispose of the device. Consumers should be given

clear instructions on how to delete their personal data.

12. Make installation and maintenance of devices easy

Installation and maintenance of IoT devices should employ minimal steps and should follow

security best practice on usability. Consumers should also be provided with guidance on

how to securely set up their device.

13. Validate input data

Data input via user interfaces and transferred via application programming interfaces (APIs)

or between networks in services and devices shall be validated.

For the full Code of Practise for Consumer IoT Security, visit:

https://www.gov.uk/government/publications/secure-by-design/code-of-practice-for-

consumer-iot-security




Appendix B: References to webinars, user guides, application notes,

and industry-related documents

Webinar material

Available on www.securethingz.com/learn

Understanding Cryptographic Keys in the IoT Secure world

Understanding Certificates in the IoT secure world

IoT Security and the use of Secure MCUs and Secure Elements

Secure Development Workflow

Security-related documents

Code of Practice for consumer IoT security

- UK Department for Digital, Culture, Media and Sport (See Appendix A)

Secure by Design: Improving the cyber security of consumer Internet of

Things Report

- UK Department for Digital, Culture, Media and Sport

Baseline Security Recommendations for IoT in the context of Critical

Information Infrastructures

- European Union Agency for Network and Information Security (ENISA)

Interagency Report on Status of International Cybersecurity Standardization

for the Internet of Things (IoT)

- US Department of Commerce (National Institute of Standards & Technology)

This white paper is produced by Secure Thingz

For more information, please contact: [email protected]

www.securethingz.com

Secure Thingz Ltd.,

Hudson House, Maris Lane,

Trumpington,

Cambridge, CB2 9FF

United Kingdom

Secure Thingz, Inc.

1065 E Hillsdale Blvd # 420,

Foster City, CA 94404, USA

© Secure Thingz 2019

http://www.securethingz.com/

Documents

Getting started with IoT security · IoT devices. The IoT Security Foundation has prepared an IoT Security Compliance Framework to provide pragmatic guidance to businesses developing