Images or other third-party material in this book are included in the book's Creative Commons license, unless otherwise indicated in a credit line for the material. Any source code or other supplemental material referenced by the author in this book is available to readers on GitHub via the book's product page, located at www.apress.com.
About the Authors
Ned Smith is a Principal Security Architect in Intel's Open Technology Center, developing trusted edge computing technologies. Within the Internet of Things, Dave has contributed to Intel's Software-Defined Industrial Systems architecture and IOTG's Health Application Platform.
Acknowledgments
This timely book will build your knowledge of IoT security challenges and solutions from the ground up, starting with the fundamental security building blocks and extending to available IoT frameworks and specific vertical applications. Please join us in the critical mission of securing IoT applications, and by extension, our future.
Introduction
More standards are being created and regulations are being adopted to address many of the security concerns of the IoT, including the protection of user data, identity and other valuable assets. Simple to implement using the relevant standard application programming interface (API), frameworks and software development kits (SDK) to develop the IoT device.
Conceptualizing
The BadUSB Thumb Drive
The lethality of attacks can be increased by chaining together different exploits that expose larger attack surfaces and allow the attacker to collect more resources for the next attack. An attack that started as a compromise of something without network connectivity can turn into a compromise of resources with network connectivity - increasing the attacker's range and lethality.
Air-Gap Security
Air-gapped security has a significant usability disadvantage in that it is expensive to deploy, does not scale well, and is not future-proof. A lesson learned from air gap security is that attention to usability cannot be ignored.
Stuxnet
The next generation of Industrial IoT focuses on other network security mechanisms, such as VLANs that segment networks, isolating production equipment behind routers, static/dynamic whitelists, and zoning/. Security mechanisms must be designed to take into account all other system requirements to find security mechanisms that optimize trade-offs.
Designing Safe and Secure Cyber-Physical Systems
The acronym Internet of Things (IoT) takes on an additional and apropos meaning of information and operational technology (IOT). Another aspect of security analysis is determining the "attack surface"13 - the environment or the sum of all points where an unauthorized user can attempt to extract information or inject control not foreseen by system designers.
Constrained Computing and Moore’s Law
Security functionality overhead for layer 1–3 systems is typically expected to be 10–15% of the total system cost. In other words, the "tinification" (the process of removing unused functionality not required by purpose-built embedded systems) of an application to match.
Trusted IoT Networks and the Network Edge
The root of trust is designed to correspond to a set of security features and assurances as the basis of trust. Secure key storage and secure cryptographic operations are important capabilities of a root of trust that can be used to implement attestation.
TEE) Contextual awareness
Trusted Computing is defined by TechTarget28 as "Trusted Computing is a broad term that refers to technologies and proposals for solving computer security problems through hardware upgrades and related software modifications." Wikipedia29 defines a trusted system as. Trusted code that implements identity and authentication primitives, including support for distributed authentication protocols such as OAuth234 and OpenID Connect.35.
Conclusion
Instead, we believe that an enlightened approach sees the value of a network as greater than the sum of its finite endpoints. With such a perspective, it will be more feasible for the most important IoT security technology to exist at the right levels of the IoT pyramid.
IoT Frameworks and Complexity
This chapter is long relative to the other chapters in part because there are many IoT framework standards available and each takes a different perspective. Nevertheless, we encourage continued IoT framework evolution that removes unnecessary complexity and puts security by design at the center.
Historical Background to IoT
When IoT systems are built to integrate with existing systems based on fieldbus protocols, IoT systems are sometimes called degraded IoT because they represent use cases, ecosystems, and solutions that existed before the introduction of Internet technologies. Whether the system is a degraded system that connects an existing industrial or manufacturing automation control system with Internet technology, or a new system that uses completely new protocols and devices, both instances of IoT systems bring a level of complexity that requires some abstractions to improve the efficiency of application development and enable the management of these systems.
IoT Ecosystem
Just as the changes in Internet protocols brought more complexity to computer networks in the 1990s, Internet of Things technology promises more complexity (at least initially) for industrial, control and automation systems. We consider the following application to be adjacent to the Internet of Things, but not part of it: Car sharing, ePayment.
Connectivity Technology
Messaging Technology
Broadcast and multicast can make public-subscribe more efficient, which can be used in some IP-based networks. Different protocols are useful in different environments, and the entire communication stack even down to the availability of broadcast at the physical layer of the network must be considered when developing services in an IoT system.
Platform Technology
This complexity becomes more apparent when designing an IoT platform, especially when designing an IoT platform that aims to serve multiple ecosystems. IoT frameworks are used across platforms because they facilitate interoperability and connectivity by combining the right network, protocol, and platform components in ways that enable the application.
Elements of an IoT System
IoT Device
Viewed from an application perspective, the data abstractions of the IoT framework can make it difficult for application code to determine when a physical device boundary is being crossed. A single application can interact with multiple IoT framework "devices" without knowing whether they are geographically local or remote.
IoT Device Architectural Goals
To avoid confusion, the authors try to provide an explanatory context when using "device" terminology. Securing software-defined devices requires a trusted execution environment that creates reliable hardware isolation and exposes security roots of trust to the soft device.
Interoperability
Post-deployment reconfigurable layers between applications and embedded components allow system architects to make corrections during simulation and pilot deployment. Less constrained devices such as hub controllers, bridges, and gateways can contain more easily reconfigurable layers because they often support a greater variety of network interfaces and have more computing resources and storage space to draw from.
Security
Less constrained systems typically make use of multiple roots-of-trust and multiple trusted execution environments. The remote device expects to receive an attestation report signed by a trusted signing key protected by a reporting root-of-trust.
IoT Network
IoT System Management
These include security services for managing roles, access control policies, and cryptographic keys and certificates; software update services for distribution and installation of firmware, software and security patches; Access control policies may not be expressed consistently across IoT systems where role names and syntax may differ, access enforcement conventions may differ and be inconsistent, or key management.
Device Lifecycle
Manufacturing
Supply Chain
Deployment
The owner operates onboarding services that facilitate ownership transfer, supply chain provenance verification, attestation of security properties and roots of trust, issuance of credentials, security associations, roles and access control policies. Zero-touch commissioning is extremely important and difficult to get right given the diversity in the supply chain and given the spectrum of customer security and privacy expectations.
Normal Operation and Monitoring
Manage
Update
Decommissioning
IoT Framework
IoT Framework Design Goals
The top layer of the framework is specific to the IoT use case as it exposes a data model abstraction that reinforces the IoT use case context. IoT applications can be developed when given a framework abstraction and can run on any OS the framework is ported to.
IoT Data Model and System Abstractions
IoT frameworks come to the rescue by building connective intelligence into the framework—hidden from the view of applications and simplified from the view of device and network management. The framework layer may not be aware of the impact on authorization, which can cause the framework to misrepresent the actual security posture to IoT applications.
IoT Node
IoT Operations Abstraction
Alternatively, discovery can be performed by sending discovery requests to discovery interfaces for specific nodes requesting the relevant information. Passive discovery uses folders or less constrained nodes that respond instead of other nodes that may ignore all discovery requests in a low-power mode.
Note an anonymous entity may learn a tremendous amount about how an Iot network functions, the type of nodes involved, what work
Nodes managing registrations/subscriptions must maintain context for secure delivery of the notification message(s) that may involve many subscribers. Asynchronous message delivery may involve different security associations and context than those used to process registrations/subscriptions.
Connectivity Elements
Manageability Elements
Security Elements
However, this assumption of trust may not be justifiable without taking additional precautions to prove and verify hardware, firmware, software, and operational status to peer nodes.
Consider the Cost of Cryptography
Cryptographic algorithms are being designed that are believed to be secure against quantum computers, called post-quantum secure algorithms, and have led to a new branch of cryptographic study called post-quantum cryptography. However, it seems clear that where symmetric cryptography is already acceptable for the IoT, it should continue to be acceptable, as doubling the key size is the most economical quantum-secure solution.
Summary IoT Framework Considerations
IoT Framework Architecture
Data Object Layer
Security is an integral part of IoT framework layers, revealing additional security insights regarding each layer (see Figure 2-6). More sophisticated internetworking and interdomain interactions require an additional layer of security that can be useful for gateway operations.
Node Interaction Layer
The gateway application contains the control and management logic to present nodes to the IoT peer network, shadowing the actual nodes that exist deeper in the local IoT network. For example, a TLS or IP Security (IPSec) secure channel can be shared between multiple locally hosted nodes, which means the nodes must use shared credentials, something most security professionals ignore.
Platform Abstraction Layer
This approach allows the security endpoint to move from the protocol stack to the Node Interaction layer potentially simplifying implementation. The basic idea is that the security endpoint context, data packets, and node-to-node security connections must exist within a suitably hardened container as a prerequisite for performing the relevant security operations.
Platform Layer
The root of trust hardware is essential for creating and securing device identities that can be used to validate the device's security properties to a peer and to securely boot the device. Root-of-trust hardware or crypto offloading hardware often includes the entropy source needed to generate encryption keys and trusted identifiers.
Security Challenges with IoT Frameworks
In step (2), the Conn-C access path finds the TLS security association and the security context-A in the security endpoint contexts. Ideally, the security context operations are performed in a TEE that is resistant to man-in-the-box attacks.
Consumer IoT Framework Standards
A man-in-the-middle (MITM) attack can be successful if malware has found a way to intercept the data after the data protection module is complete, but before the logical device context is in place. The Security Context-A is a fulcrum in the framework that uniformly applies an IoT network security policy involving the peer nodes and Node-A.
Open Connectivity Foundation (OCF)
The semantics of the OCF interface are typically defined using RAML23 (RESTful API Modeling Language), although there is interest in moving to Swagger24, which conforms to the OpenAPI specification. The OpenAPI25 specification is an open source community effort to define robust data modeling languages and tools.
OCF Core Framework Layer
The traditional notion of a network topology consisting of nodes having routable IP addresses hides behind the abstraction of resources. A device management resource is likely to allow updating so that a management console can configure the resource for management purposes.
OCF Profiles Framework Layer
The OCF Device Abstraction
OCF resource access follows CRUDN (Create, Retrieve, Update, Delete, Notify) interaction semantics that are part of the RESTful interface definition (eg PUT, GET, POST, DELETE). This means, from the perspective of the OCF device, it is not possible to distinguish whether a peer OCF device is geographically local or remote.
OCF Security
The use of TLS also implies that there are deployment cases where the TLS endpoint is actually a gateway, proxy or firewall or some other intermediate node that is not the original OCF device. For example, a device may be in the RESET state during manufacturing and supply chain phases and then transition to RFOTM to enter the deployment phase.
AllJoyn Security
For example, IP multicast can be an efficient way to send the same message to multiple recipients. AllJoyn bridges perform network and link layer translations when AllJoyn nodes are physically separated or when AllJoyn framework-level objects are inserted into a different IoT framework environment.
Universal Plug and Play
Discovery: Service discovery automation is achieved through proactive “live” messages that are periodically broadcast to listening checkpoints. Checkpoints that need to be evaluated for service changes and mutable state can be registered for asynchronous notifications when things change.
UPnP Security
Notification messages are small; if the control point needs more information than is available in the notification message, it may need to follow the notification with a request-response interaction. CommandSensor: Control points can change IoTMManagementAndControl properties in the data model (which is a data repository object).
Lightweight Machine 2 Machine (LWM2M)
LWM2M Architecture
An object instance ID is added between the object ID and the resource ID to qualify the object instance. The URI path examples have three elements, the middle one being the Object Instance Identifier (indicated by a blue arrow).
LWM2M Device Management
Firmware Update: Client nodes report the firmware version and firmware packages can be installed via the firmware update object. This seems reasonable since the primary goal of LWM2M is device management, where the device uses management service providers that launch and configure the client.
LWM2M Security
95 ACL support is achieved by using the Bootstrap server to provide access control resources to LWM2M clients seeking access to LWM2M servers. In the following example, the Bootstrap server provides a security object in client 1 with an ACL object with read and write access to server 1 (eg, ACL:
One Machine to Machine (OneM2M)
Device Management: These functions address device management capabilities associated with OneM2M nodes and may use existing IoT device management frameworks such as TR-069 and LWM2M or may define new functions. Device management functions translate data, protocol and semantics from one management node to another using a Management Adapter module.
OneM2M Security
Hiding this complexity from system designers can have unintended consequences, while exposing flexibility (with simplified apparent complexity) to applications and users can also have unintended consequences.
Industrial IoT Framework Standards
Industrial Internet of Things Consortium (IIC) and OpenFog Consortium
However, the reader might appreciate the role of a reference architecture in evaluating IoT frameworks as building blocks of IIS systems. The IIC deployment viewpoint reference architecture (Figure 2-23) captures an important three-layer network topology structure that recognizes an Edge Tier network consisting of sensor, actuator, and controller nodes that can share latency, resiliency, and QoS requirements typically met by edge-class technologies.
Open Platform Communications-Unified Architecture (OPC-UA)
OPC-UA is a device-centric technology that connects sensor, actuator, and PLC (programmable logic controller) devices to each other and to a larger system of computing and server-class platforms. 113 The basic structure of an OPC-UA network consists of an OPC client connected to an OPC server.
OPC-UA Framework Architecture
Client nodes can specify filter criteria applied to monitored data values when determining when it is appropriate to notify the client. The OPC-UA framework has several built-in information models (Figure 2-26): Data Access (DA), Alarms and Conditions (AC), Historical Access (HA), and Programmable State Machines (Prog).
OPC-UA Security
The associated specifications define what information is exchanged, while the OPC-UA information access layer defines how information is exchanged. OPC-UA applications undergo a two-step access process where they first access servers and second access data.
Data Distribution Service (DDS)
Data writers offer a QoS promise on published data based on the data reader's requested QoS level. DATA_LIFECYCLE: Controls how persistent or temporary data is relative to the availability of either the data writer or data reader.
DDS Framework Architecture
The Device System layer exposes built-in device capabilities to the DDS framework through accessible interfaces. DDS domains have global data space (Figure 2-32), which means that items are visible to all data writers and readers that are members of the same domain.
DDS Security
Security Enveloping
If the RTPS submessage requires confidentiality protection, the serialized payload of the submessage is encrypted and forms a CryptoContent element consisting of a CryptoHeader and a CryptoFooter. All RTPS message submessages belonging to an RTPS message are associated with a second security wrapper layer consisting of the SecureRTPSPrefix, SecureRTPSPostFix, and SecureBody elements.
Security Tokens
The PermissionsToken contains summary information about the permissions of a domain participant in a way that can be externalized and propagated over DDS discovery. Permissions Tokens: The PermissionsCredentialToken encodes the permissions and credentials of a domain participant in a way that can be externalized and sent over a network.
Security Plugin Modules
It is used by an access control plugin that manages domain access and specific reader-writer interactions. For example, DDS does not appear to support authentication protocols that query the peer principal's security subsystem to provide proof of device origin and the integrity of system firmware, software, plug-ins, and the DDS framework layer.
Framework Gateways
Dell's EdgeX Foundry50 takes a slightly different approach enabling services at the edge, where edge refers to both the edge of the IoT network and the edge of the cloud hosting environments. The IoT framework standards organizations seem to understand that a multitude of "standard" IoT frameworks hinders one of the main motivations for IoT frameworks – interoperability.
Framework Gateway Architecture
133 But these efforts are solutions to an interoperability problem created by the industry's eager response to an IoT interoperability problem. Ironically, the "success" of the IoT seems to have created a more complex environment for IoT interoperability as both standard and proprietary.
Framework Gateway
Framework Gateway
See the "Security Considerations for Framework Gateways" section for more insight on interdomain bridging considerations.
Framework Gateway
A traditional frame may not be considered a Type III gateway, depending on the set of protocols and message types that the frame supports. However, given Framework A support for HTTP only and Framework B support for CoAP only, the type III gateway translation comes into play.
Framework Gateway
Security Considerations for Framework Gateways
Modification of data objects and protocol messages protected by integrity and confidentiality necessarily implies that the gateway is authorized and trusted to perform these transformations. In general, the gateway is expected to be one of the most trusted nodes in the network.
Security Endpoints Within the Gateway
Security Endpoints in Type I Gateways
Security Endpoints in Type II Gateways
Security Endpoints in Type III Gateways
Security Endpoints in Type IV Gateways
One important consideration is whether the interaction with framework B allows access to supersets of data objects that are not normally part of subsets of the objects of framework B. Given this scenario, a boundary crossing occurs at the line where superset and subset objects intersect.
Security Framework Gateway Architecture
145 A prominent feature in our idealized framework architecture is the addition of the Security Object layer that contains commonly specified and understood security objects and data model representations. Using the Security Object layer of the Secure Execution resource preserves its isolation properties with respect to other layers.
Summary
New and existing proprietary approaches also seem to have taken hold as the IoT has grown in size. Frame gateways are placed at the edges of IoT networks and address interoperability needs, but they should also be considered the most trusted security checkpoints, as crossing organizational domains often coincides with translation from one IoT network protocol to another.
Base Platform
Security Hardware Building Blocks
The second class of security functions is implemented in the isolated security engines, with examples including the Converged Security and Manageability Engine (CSME). Please note that at the time this book is published some new security features may be released by intel and therefore please.
Note please note that by the time this book is published, some new security features may be released by intel, and therefore please
This chapter dives into the rich set of security and privacy technologies that Intel has available in their product lines and how they can be used to implement secure IoT systems.
Background and Terminology
Assets, Threats, and Threat Pyramid
A real-life scenario for protecting assets in our home would be to protect house keys (hanging on the wall), wallets (put in a locked cabinet), passports, and jewelry (in a safe in the master bedroom).
Inverted Threat Pyramid
The effort to create exploits at the top of the inverted pyramid is low and the ROI on the compromised assets is also low. As we go through the inverted pyramid, the effort required to create exploits increases significantly along with the cost, and therefore the number of exploits tends to be lower and targeted in nature.
Sample IoT Device Lifecycle
The provisioning/configuration phases require tools that can scale across CPU families and assign a persona to the IoT device. Refer to Secure Device Onboarding technology for detailed supply chain interaction throughout the lifecycle.3.
End-to-End (E2E) Security
The device has/interfaces to sensors (smart/dumb) and actuators, collects data and controls the sensors and drives the actuators. The device encrypts or signs (or both) (depending on the policy) the data and sends it to the Gateway.
Security Essentials
Device Identity
SWFP is an important aspect of secure boot on a platform where the goal of secure boot is to detect malicious changes to software images before they are loaded into memory. The TCG defines methods for securely booting a platform where the SWFP of each software image loaded into memory is measured (also called cryptographically hashed) in a Platform Configuration Register (PCR) securely stored by a TPM.
Protected Boot
An IoT system that enforces a common and authenticated secure boot policy is a way to establish trust in a distributed set of IoT nodes. Intel® TXT (Trusted Execution Technology) anticipates scenarios where a hard power reset, as a way to return to a trusted environment, is impractical.
Protected Storage
Intel® QuickAssist Technology (QAT) is a hardware data encryption accelerator that also implements keystore protection. In some cases, the key hierarchy itself is too large to fit into hardware-protected storage; therefore, intermediate keys can be used to encrypt data encryption keys and so on until the top keys in the hierarchy can be stored in hardware.
Trusted Execution Environment (TEE)
It is common to build a hierarchy of data encryption keys so that different access and lifecycle controls can be applied to different data. CSME can be used to offload security-sensitive operations to protect them from potential attacks from the normal CPU environment.
Built-In Security
At the bottom layer, Intel Architecture allows the use of integrated security features to build platforms in the middle layer and, at the top layer, to create enriched ecosystems by deploying best-in-class security software solutions. These upper-layer solutions enable protection, detection and remediation in both consumer-grade and enterprise-grade solutions.
Base Platform Security Features Overview
CPU Hosted Crypto Implementations
CPU security features and accelerators are available for trusted execution environments implemented by the CPU, including Intel® SGX, Intel® VT, and Intel® TXT.
Malware Protection (OS Guard)
OS Guard (SMEP)
OS Guard (SMAP)
Encryption/Decryption Using AES-NI
Vector AES is a promotion of AES-NI in vector form, enables two (256-bit) or four (512-bit) lanes and increases AES core throughput. AESIMC and AESKEYGENASSIST: Assist with AES key expansion, AES reverse hashing columns, and AES key generation assistance.
Sign/Verify Using Intel ® SHA Extensions
