Foundations first: putting the basics of IoT security in place
As Embedded and Internet of Things (IoT) devices grow in capability, making them more secure has become a critical priority for product manufacturers to master.
Since Apple launched the first iPhone® in 2007, consumers all over the world have become used to carrying or wearing powerful computers on their person, and using embedded computers to perform functions such as controlling heating and ventilation, navigating in their car, or streaming entertainment on their TV.
In fact, demand for digital technology is on a long-term trend of growth across almost every domain of modern life, from leisure and entertainment, healthcare and wellness, mobility and shopping to home automation and home appliances. Adding artificial intelligence (AI) capabilities significantly increases the value and competitive potential of these connected products. In all of these embedded applications of digital technology, a connection to the internet is essential, via either a wired connection, typically an Ethernet network, or via a Wi-Fi® or other wireless network connection. And an internet connection is a risk: while the internet opens up a device’s access to legitimate and authorized service or data providers, it also exposes the device to the hackers, malware and cyber-attackers who want to compromise devices, networks, services or people remotely via the world’s universal network. This threat applies as much to commercial and industrial IoT devices as to consumer products.
As these devices become more and more sophisticated in response to industry demand, they also become more complex. The more complex a product, the greater the attack surface available to cyber attackers, and the harder the task of shutting off every potentially vulnerable point of entry for a hacker or malware.
This is particularly true for the many connected embedded devices that are based on a Linux® operating system (OS): the Linux platform is constantly evolving and developing, and since it is open-source software, the manufacturer which embeds a Linux OS in its product is responsible for its maintenance.
Edge computing environments are prime targets: according to the European Commission, a ransomware attack occurs every 11 seconds, costing the world approximately €20bn in 2021. And in 2021 alone, the EC says, 10 million distributed denial of service (DDoS) attacks were launched.
Need for end-to-end protection
In IoT security, the concept of protection does not just apply to the hardware components, or even just to the device’s combination of hardware and software.
Cyber attackers ruthlessly hunt for the weakest link in the chain of security, wherever it is between the device and the cloud. This means that cybersecurity protection has to apply equally to the hardware, firmware, software, and network connections on which a device is based.
Effective embedded systems security requires an end-to-end architecture that accounts for every component and connection in the device lifecycle.
Maintaining product and brand value
The losses suffered when an IoT device’s security is compromised have wide-ranging effects. The most direct loss is in the cost for the device manufacturer to remedy the underlying vulnerability, which can require the deployment of an expensive emergency engineering task force.
Another increasingly important direct cost is the fine which could be levied by authorities when a successful exploit reveals a breach of a cybersecurity regulation.
The indirect costs go even wider: the risk of the loss of buyers’ or users’ trust in the product, and in the brand of the product’s manufacturer. Affected users could also pursue the manufacturer for damages or losses caused when an IoT device or service is compromised or disabled.
Reliability has always been a critical design priority for embedded systems engineers. Today, a crucial determinant of a product’s reliability is its implementation of embedded systems security, underpinning its ability to repel cyber attacks.
Key threats and challenges in IoT security
IoT devices face a wide range of evolving cyber threats. The types of attacks to which devices are exposed are of three main types:
- Attacks on device firmware or software
- Attacks on device hardware
- Attacks on services or network connections on which devices depend
Firmware and software attacks
The most common types of cyber attack on the software or firmware in a connected embedded device include:
- Exploiting default or weak credentials – many IoT devices ship with a default password which the user never changes. Attackers can find these credentials in product documentation or through simple brute force attacks.
- Exploiting vulnerabilities in firmware, including buffer overflows, command injection flaws, and hardcoded backdoor accounts.
- Exploiting an insecure over-the-air (OTA) update mechanism, made possible when firmware updates are unencrypted or code signing is not properly verified. Updates are also vulnerable to man-in-the-middle attacks during update downloads. Here, attackers intercept and manipulate communication between IoT devices, potentially stealing data or injecting malicious commands. DNS spoofing enables an attacker to redirect an IoT device to malicious update servers.
- Exploiting unprotected firmware when the device powers up – a secure boot process helps ensure that only an authenticated image of the device’s firmware is loaded at start-up. Without systems like this, attackers can replace legitimate firmware with malicious versions, or bypass runtime security controls.
Attacks on device hardware
With physical access to devices, attackers can:
Extract firmware through debug interfaces such as UART or JTAG interfaces
Access Flash memory directly
Exploit hardware-level vulnerabilities, for instance by performing a side-channel attack to uncover security keys or other secrets through analysis of power system behavior or other physical parameters
Attacks on services or infrastructure
Attackers can target the supply chain which supports an IoT product manufacturer, for instance to:
Compromise firmware before a device is shipped from the factory
Insert malicious code during the manufacturing process
Create counterfeit devices with built-in backdoors
Another vulnerability is the cloud service on which IoT devices depend. Attackers can:
Exploit insecure application programming interfaces (APIs)
Bypass insecure authentication procedures
Exploit weak server security protections
Another vector for cyber attacks is the network to which an IoT device is connected. Once on the same network, attackers can:
Sniff unencrypted traffic
Exploit insecure protocols
Perform Address Resolution Protocol (ARP) spoofing to intercept communications
Use distributed denial of service (DDoS) attacks to overwhelm IoT devices with traffic, making them unavailable to users
Urgent need to design products for compliance with cybersecurity regulations
IoT security is a high priority for embedded systems manufacturers not only because their products are at risk: they also face a legal obligation to put specified cybersecurity protection measures in place in many parts of the world.
One well known law is the European Union’s Cyber Resilience Act, which makes digital product manufacturers responsible for the cybersecurity protection of their products for life – in other words, not only when the product is shipped from the factory, but also afterwards, when the device is in the possession of its end user.
This calls for the implementation of the foundations of security protection, including secure boot, OTA updates, cryptography, and secure key management.
The European Union has also enacted the General Data Protection Regulation (GDPR), which requires measures to ensure that device users are able to keep personal data private.
Other notable cybersecurity laws include:
US’s Cybersecurity Improvement Act, which requires IoT devices purchased by the federal government to meet minimum security standards.
US’s California SB-327, which requires ‘reasonable’ security features for connected devices sold in California.
US NIST SP 800-213 – guidelines for IoT device manufacturers which are non-binding but influential.
EU’s Radio Equipment Directive (RED) – includes cybersecurity requirements for radio equipment.
ETSI EN 303 645, a European standard for IoT security. It is voluntary, but more and more regulations refer to it.
UK’s Product Security and Telecommunications Infrastructure Act – mandates security requirements for consumer connectable products.
UK’s Code of Practice for Consumer IoT Security – voluntary guidelines which influenced ETSI EN 303 645.
Singapore's Cybersecurity Labelling Scheme for smart home devices.
China's Cybersecurity Law – imposes security requirements on network equipment and critical infrastructure.
South Korea's IoT Security Certification Program, a voluntary certification scheme for IoT devices.
Global standards include:
ISO/IEC 27400: information security guidelines for IoT devices.
ISO/IEC 30141: a reference architecture for IoT systems.
IoT Security Foundation's Compliance Framework of industry-led best practices.
Widespread failure to comply with security standards and best practices
Despite the pressure for IoT device OEMs to implement strong cybersecurity protection in their products, many companies are failing today to build and maintain an end-to-end security architecture.
Typical vulnerabilities in products on the market today include:
- Failure to implement secure boot processes, leading to weak authentication of the device’s firmware image
- Inadequate encryption and key management measures for protecting important security assets such as private keys, both on-device and at the OEM, compromising their secrecy
- Failure to provide a secure mechanism for the delivery and deployment of OTA updates
- Lack of a software bill-of-materials (SBOM), or failure to maintain an up-to-date SBOM, for all production units leaving the factory and installed in the field. This makes it difficult or impossible for the OEM to provide a timely and appropriate response to new Common Vulnerabilities and Exposures (CVE) notices, leaving devices open to known threats because they cannot be identified as vulnerable.
On top of this, IoT device OEMs are constrained by the limited compute and memory resources available on their devices for implementing intensive security measures such as cryptography.
IoT security fundamentals: the essential measures to implement
Effective cybersecurity protection in IoT devices has to be based on essential foundations – the building blocks which enable protection operations to run when required.
Secure boot and a root of trust
Secure boot creates a chain of trust during the device boot process by cryptographically verifying each component before execution. This helps to resist unauthorized or malicious code from running during start-up.
To implement a secure boot process, a device will typically follow these steps:
The manufacturer programs in an immutable root of trust (often in ROM) with cryptographic keys
Each boot component is digitally signed by the manufacturer
When powered on, the root of trust verifies the signature of the first bootloader
Each verified component then checks the next component in the chain
If verification fails at any point, the boot process halts
This creates an unbroken chain of trusted code from power-on to the application layer.
Encryption and key management
The ability to encrypt and decrypt data is a fundamental feature of IoT security. Key management helps ensure that the keys used in cryptographic operations remain secret, and available for use only by authorized devices. Key management utilities supported by DevOps and DevSecOps platforms enable OEMs to scale up and automate key management over fleets of thousands or millions of production units.
Cryptography in connected embedded devices is generally supported by hardware cryptographic accelerators in SoCs, application processors and microcontrollers, as well as by software security applications.
Cryptographic operations underpin essential security capabilities, including:
- Device authentication
- Security-rich data communication and storage
- Supply chain security, resisting vulnerabilities introduced during manufacturing, where compromised encryption keys could affect entire product lines
Access control and protected user identity
In IoT devices, a method is required for denying access to anyone except an authorized user. In a smartphone, this access control is often implemented biometrically (for instance face or fingerprint recognition), or with a unique PIN known only to the user.
In commercial or industrial IoT devices, access control will often require more sophisticated management to allow a set of multiple users to be authorized, and for authorizations to be granted or revoked when necessary. The access control system should be flexible enough to allow for role-based permissions, where different users have different access rights depending on the requirements of their role.
In addition, each device requires a strong, unique identity expressed in the form of certificates or tokens. Where practicable, multi-factor authentication provides for stronger access control. In addition, access decisions should be based not only on the device’s identity, but also its state and behavior.
Secure access control measures are normally underpinned by the implementation of zero trust policies. A zero trust architecture operates on the principle of ‘never trust, always verify’. This requires:
- Continuous authentication and authorization for every device interaction
- Micro-segmentation to isolate IoT devices from each other and from core networks
- Least-privilege access, limiting device capabilities to only essential functions
- Continuous threat monitoring and logging of device behavior, to enable real-time anomaly detection, and an active response to security incidents
Best practices for securing IoT devices
The building blocks of IoT security enable the implementation of the fundamental practices of cybersecurity protection. These are the processes and capabilities that an OEM will want to implement in an IoT device to help resist the widest possible range of known cyber threats.
The practices fall into four categories:
- Device-level protection
- Maintenance of protection
- Monitoring of protection status
- End-of-life security
Device-level protection measures
The security protection measures implemented on-device have to take account of the constraints on embedded systems security – the restrictions on processor bandwidth, memory capacity, and power consumption.
With this in mind, the most important security capabilities to integrate into an IoT device are:
Secure boot - to verify firmware integrity before execution
Cryptographic acceleration – to enable code signing backed by strong cryptographic signatures, and to enable encryption of data in storage or in transit
Device authentication mechanisms - certificates are preferable to passwords
Role-based permission to control access to the device
A hardware security module or trusted platform module to store and use secure keys, providing a sound hardware basis for encryption and key management
Disable unnecessary ports and services and remove unnecessary software and services
Disable debugging interfaces in production
Implement principle of least privilege for all functions as part of a zero trust architecture
Segment networks to isolate IoT devices from critical systems
Implement TLS for communications
Implement tamper detection mechanisms
Implement a trusted execution environment to resist vulnerable or sensitive peripheral systems
Implement lightweight logging of security events
Configure automatic alerting for suspicious activities
Enable remote device health monitoring
Maintenance of protection
The embedded systems security implemented in a device in the factory is at risk of becoming outdated from the moment that it is shipped to the end user. This is because the world is exposed to a constant stream of new threats and exploits developed by hackers, hostile state actors and others.
Known emerging threats are documented in CVE notices. According to regulations such as the European Union’s Cyber Resilience Act, device manufacturers have a duty to update devices in the field to remove any exposure to new threats.
The means to do this across a large or distributed fleet of devices is via over-the-air (OTA) updates. This means that cybersecurity protection requires a product manufacturer to build OTA capability into its devices, and to establish a secure, authenticated, and robust OTA framework which enables it to develop, deliver and deploy security patches and firmware upgrades to all at-risk devices in the field.
Many OEMs choose to do this with The Upgrade Framework (TUF), an open source update framework which embeds strong security features to reduce the risk that updates themselves become a vector for cyber attacks on devices.
The manufacturer should also have a method for maintaining and updating a software bill-of-materials (SBOM) for each production unit, to take account of changes in the code base introduced with each installed update package.
Monitoring of protection status
Even with the recommended cybersecurity processes and capabilities in place, manufacturers cannot assume that their devices are safe in perpetuity: the continuing effectiveness of protection needs to be monitored by performing systematic risk assessments and regular security testing throughout the device lifecycle.
Monitoring efforts should include threat modeling and penetration testing. Effective threat modeling typically involves:
- Device mapping and asset inventory - documenting all components, connections, data flows, and trust boundaries
- Attack surface analysis - identifying all potential entry points, such as physical ports, wireless protocols and APIs
- Threat enumeration – threats are often categorized as STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege
- Attack tree development - mapping potential attack paths through the system
- Mitigation planning - developing specific countermeasures for each identified threat
End-of-life security
Cyber threats to a fleet of devices persist even after the end of individual devices’ lives. Secrets and other data mined from discarded devices can be used to compromise existing devices. This means that lifecycle management of IoT devices needs to continue through to secure disposal or decommissioning.
Key steps in secure decommissioning include:
Data sanitization
Secure data wiping capabilities that meet NIST 800-88 standards
Complete removal of all sensitive information, credentials, and encryption keys
Validation processes to confirm complete data removal
Factory reset mechanisms
Robust factory reset functionality accessible through both physical and digital means, to restore the device to its original state and remove all user configurations
Verification mechanisms to confirm successful completion of the reset process
Remote decommissioning
- Implement a capability for authorized remote decommissioning and data wiping, backed by authentication protocols to prevent unauthorized decommissioning
Revocation of device authentication
Remove device credentials from back-end authentication systems
Revoke all certificates and access tokens
Update certificate revocation lists (CRLs) to prevent future authentication
Physical destruction
The OEM might need to consider how hardware security modules or trusted platform modules might be physically destroyed if they contain highly sensitive data
Include seals to indicate whether devices have been tampered with
These decommissioning processes should be supported by a robust fleet management framework, to enable the OEM to maintain records of all devices and their decommissioning status, to establish a proper chain of custody for all decommissioned hardware, and to enable it to generate audit reports for verification and compliance purposes.
Adopting a DevSecOps approach to IoT security
The old model of IoT device manufacturing was to ‘ship and forget’: after an embedded device reached the end user, often the manufacturer had no more responsibility for it, or to its user.
The constant evolution of cyber threats means that this is no longer the case, and manufacturers have to be capable of continually developing, releasing and delivering software updates remotely. This continual cycle of development and deployment to supplement an existing code base favors the implementation of a DevSecOps approach to device management over the entire lifecycle.
Typical features of a DevSecOps framework include a CI/CD (Continuous Integration/Continuous Development) method of software development. A DevSecOps framework also naturally supports a security-first approach, in which security requirements are addressed from the start of a new design project.
DevSecOps platforms facilitate cross-functional working, so that hardware, software, quality assurance and security specialists work together to maintain consistent security practices.
The particular benefits of implementing a DevSecOps approach include:
- Integration of security into the development process from the earliest phases of a design
- Security testing through CI/CD pipelines, automating vulnerability scanning, SAST, DAST, and dependency checks. This means that the OEM catches security vulnerabilities early, when they are less expensive to fix
- Automating the generation and maintenance of a software bill-of-materials (SBOM)
- Supporting a security-rich firmware update infrastructure
- Facilitating compliance management
- Supporting security monitoring and response
- Enforcing security-rich settings by default through automation
How the FoundriesFactory platform helps manufacturers implement superior IoT security
The requirements for effective cybersecurity protection of IoT devices call for end-to-end integration of security design and implementation practices, from the beginning of a device design project, through testing, production and commissioning, to end of life and secure disposal.
This is best achieved within the framework of a DevSecOps system. Foundries.io supplies a comprehensive DevSecOps system with its FoundriesFactory platform. The platform is supported by the Linux microPlatform (LmP), a lean Linux distribution for embedded devices which is supported and maintained by Foundries.io.
Key features of the FoundriesFactory platform include:
Unified platform for development and production: enables the integration of security tools throughout the development and deployment flow, backed by consistent policy enforcement from prototype to production.
Security-focused OTA update system: based on The Update Framework (TUF), an open-source software utility, the FoundriesFactory update system provides a security-focused approach to the development, delivery and deployment of over-the-air security updates and patches.
Security-rich software baseline: the LmP Linux distribution, which is supported by timely security software updates supplied by Foundries.io, provides a strong basis for the development of security-focused IoT devices.
Integrated CI/CD pipelines: the FoundriesFactory platform’s development and implementation processes incorporate security at every stage, so end-to-end security features are in place in IoT devices.
Scalable device management: advanced monitoring and fleet management capabilities to keep devices up to date. A continuously updated software bill-of-materials (SBOM), unique to each production unit, enables OEMs to automate CVE monitoring and initiate timely responses when relevant threats are detected.