Getting started with IoT security

Getting started with IoT security

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 importance of security in connected devices is starting to drive government and security agencies to push for legislation. This is creating awareness amongst companies and their managers responsible for the development of these connected devices. However, due to the complexity of security it is difficult for development engineers to know where to start!

In this article, we attempt to put a structure and flow in place that a product design team should follow during the development of a connected device. The flow will help developers with key aspects such as awareness of up and coming legislation and the industry best practises.

Codes of Practice

Government agencies have become aware of the threat posed by non-secure IoT devices. Studies and reviews of the technology have resulted in prepared publications with recommendations. In addition, the IoT Security Foundation has prepared an IoT Security Compliance framework to provide pragmatic guidance to businesses who are 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, APIs, platforms and more.  It is recommended that business managers and developers study these documents in order to understand the impact of security on their product design.

Examples of government studies are listed below:

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)

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.


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.

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.

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. 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.

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.

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?
  • 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. and how will security continue to be enforced after the product has been manufactured?

  • Secure software updates?
  • System compromised?
  • Customer data protected?

Further details of these important stages are highlighted in the webinar Secure Programming Workflow available on the Secure Thingz website along with the white paper that includes the full text version of this article entitled Getting Started with IoT Security  It is recommended that the reader review both the webinar material and white paper at the earliest stage of IoT product development.

                                                IoT product development workflow


But what tools can Secure Thingz and its partners make available to the development engineer to simplify the complex steps highlighted in the flow? Let us examine the IAR Systems tools that are available to aid the development process.

Embedded Trust

Embedded Trust/C-Trust is a security development environment providing streamlined security development in IAR Embedded Workbench. The environment leverages the secure hardware built into next-generation microcontrollers to provide the low-level trust anchors and secure services needed for trustworthy IoT solutions:

  • Integrated identity and certificate management
  • Scalable Secure Boot Manager
  • Secure deployment with integrated manufacturing mastering
  • Release management with versioning and update infrastructure

Embedded Trust/C-Trust is fully integrated with the complete development toolchain IAR Embedded Workbench. The integration enables the OEM/Customer to include security development as part of their day-to-day workflow, while making sure their code is fast, efficient and highly compact. Embedded Trust encompasses many of the tasks required when developing an IoT product.

                                       Embedded Trust in the IoT product development flows


Embedded Trust simplifies the following development flow processes:

  • Identity creation
  • Provisioning
  • Mastering
  • Secure Deployment

Secure Deployment

Once all the development processes have been completed, it is important that the final software image is protected during the manufacturing process against IP theft, cloning and over-production. Embedded Trust creates the keys and certificates required to implement a secure programming workflow which includes the encryption of images during manufacture and end customer software updates. The exporting of the software image is invoked using the “Production Export” function available in the tool. This allows the user to export the encrypted and signed software image to a secure programming service provider.

© IAR Systems 1995-2020 - All rights reserved.

We use cookies on this website to provide you with a better experience. You need to accept cookies to continue using this site. Cookies