CANCEL
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Philippines
Mexico
Thailand
Ukraine
Luxembourg
Estonia
Lithuania
Norway
Chile
South Korea
Ecuador
Colombia
Taiwan
Switzerland
Indonesia
Cyprus
Denmark
Finland
Poland
Malta
Czechia
New Zealand
Austria
Turkey
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Malaysia
South Africa
Netherlands
Bulgaria
Latvia
Japan
Slovakia
The IoT world forum reference model describes seven levels of an IoT ecosystem. These levels are as follows:
We will borrow these seven levels to explore and discuss the makeup of the IoT ecosystem.
There are so many different types of things within the IoT that it becomes difficult to prescribe security recommendations for the development of any one in particular. At their core, however, IoT devices are hardware-based and contain sensing and communication capabilities. They may also support actuation, storage, and processing capabilities.
Popular IoT development boards include Arduino, Beagle Board, Pinocchio, Raspberry Pi, and Cubieboard, among others. These development boards are used for prototyping IoT solutions. They include microcontrollers (MCUs), which serve as the brains of the device, provide memory, and a number of both digital and analog General Purpose Input/Output (GPIO) pins. These boards can be modularly stacked with other boards to provide communication capabilities, new sensors, sactuators, and so on to form a complete IoT device.
MCUs well suited for IoT development come from ARM, Intel, Broadcom, Atmel, Texas Instruments (TI), Freescale, and Microchip Technology, among others. MCUs are Integrated Circuits (ICs) that contain a processor, Read-Only Memory (ROM), and Random Access Memory (RAM). Memory resources are frequently limited in these devices. Often, manufacturers IoT-enable physical products by augmenting the MCUs with complete network stacks, interfaces, and RF/cellular transceivers. All of this horsepower is going into system-on-chip configurations and miniaturized daughter boards (single board computers).
In terms of IoT sensor types, the sky's the limit. Examples include temperature sensors, accelerometers, air quality sensors, potentiometers, proximity sensors, moisture sensors, and vibration sensors. These sensors are frequently hardwired into the MCU for local processing, responsive actuation, and/or relay to other systems.
IoT devices often employ a Real-Time Operating System (RTOS) for process and memory management, as well as utility services supporting messaging and other communications. The selection of each RTOS is based on needed performance, security, and functional requirements of the product. There are many RTOS available, including those noted here:
|
TinyOS |
Optimized for low-power embedded systems. A framework that incorporates components that support development of an application-specific operating system. Written in NesC, which supports event-driven concurrency. Refer to http://www.ann.ece.ufl.edu/courses/ee16935_10spr/papers/tinyos.pdf. |
|
Contiki |
Supports IP, UDP, TCP, and HTTP, as well as 6loWPAN and CoAP. Designed for operation in low-power systems. Supports link layer encryption for 802.15.4 communications. |
|
Mantis |
Embedded operating systems for wireless sensor platforms. Includes a kernel, scheduler, and networking stack. Supports remote update and remote login. Incorporates a sleep mode for power savings. Refer to: Sha, Carlson, et al. Mantis OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms. ACM Digital Library. |
|
Nano-RK |
Tailored for surveillance and environmental monitoring applications. Supports energy-efficient mode of operation and preemptive multitasking. Runs on 2 KB RAM and 18 KB ROM. |
|
Lite-OS |
Supports a wirelessly accessible shell and a remote debugging system. Runs on 10 KB. |
|
FreeRTOS |
A general purpose RTOS. Supports add-on TCP networking and secure communications (TLS). Implementers can use cryptographic libraries such as WolfSSL with FreeRTOS. |
|
SapphireOS |
Supports mesh networking and device discovery. Includes Python tools and a RESTful API server. |
|
BrilloOS |
Runs on 32 to 64 MB RAM and optimized for consumer/home-based IoT devices. |
|
uCLinux |
Embedded Linux supports a variety of user applications, libraries, and tools. Learn more about uCLinux at http://www.uclinux.org/pub/uClinux/FAQ.shtml. |
|
ARM Mbed OS |
Incorporates a supervisory kernel (uVisor) that supports creation of isolated security domains on ARM Cortex M3, M4, and M7 MCUs with a Memory Protection Unit (MPU). Refer to https://www.mbed.com/en/technologies/security/uvisor/. |
|
RIOT OS |
Runs on 8-, 16-, and 32-bit platforms. Includes TCP/IP stack and supports 6LoWPAN, IPv6, UDP, and CoAP. Supports multithreading and requires 1.5 KB RAM and 5KB ROM. |
|
VxWorks |
Here are the two versions (VxWorks and VxWorks+). Includes optional add-on security profile with secure partitioning, secure boot, secure runtime, loader, and advanced user management. Supports encrypted containers and secure networking. |
|
LynxOS |
Supports TCP/IP, IPv6, and cellular communications. Supports 802.11 WiFi, ZigBee, and Bluetooth. Includes encryption support, access controls, and auditing and account management features. |
|
Zephyr |
Open source designed for resource-constrained systems. Project included a heavy focus on secure development practices. Implements nano-kernel and micro-kernel and supports Bluetooth, Bluetooth-LE, and 802.15.4 6LoWPAN. |
|
Windows 10 IoT |
Supports bitlocker encryption and secure boot. Includes DeviceGuard and CredentialGuard features. Supports updates through Windows Server Update Service (WSUS). |
|
QNX (Neutrino) |
Operating System often used in vehicle infotainment systems. Includes security features such as sandboxing and fine-grained access controls. |
|
Ubuntu Core |
A read-only root file system, security sandbox for applications and separate (independent) update of applications from the OS. Allows categorization of applications as trusted or untrusted and supports Unified Extensible Firmware Interface (UEFI) secure boot. Learn more at https://developer.ubuntu.com/en/snappy/guides/security-whitepaper. |
|
OpenWRT |
A popular open source OS used often in wireless routers. |
|
GreenHills IntegrityOS |
A higher-assurance operating system. |
Many IoT device profiles are shrinking to small but powerful SoC units, capable of running a variety of secured-boot operating systems, featuring strict access controls, process isolation, trusted execution environments, kernel separation, information flow control, and tightly integrated cryptographic security architectures. Safety-critical IoT devices employ RTOS that meet industry-specific standards. Examples of these include the following:
Other critical security attributes pertain to security configuration and the storage of security sensitive parameters. Often configuration settings that are applied to an operating system are lost upon power cycle without battery-backed RAM or some other persistent storage. In many instances, a configuration file is kept within persistent memory to provide the various network and other settings necessary to allow the device to perform its functions and communicate. Of even greater interest are the handling of the root password, other account passwords, and the cryptographic keys stored on the devices when the device is power-cycled. Each of these issues has one or more security implications and requires the attention of security engineers.
End-to-end connectivity between edge devices and web services may be provided by a series of physical and cloud gateways, each aggregating larger quantities of data. Dell, Intel, and other companies market IoT gateways. Companies such as Systech offer multi-protocol gateways that allow for many types of IoT devices to be connected together, using multiple antennas and receivers. There are also consumer-focused gateways, also called hubs, available in the commercial market, that support smart home communications. The Samsung SmartThings hub is one example of this.
Xively, ThingSpeak, and others offer flexible development solutions for integrating new IoT devices into enterprise architectures. In the domain of smart cities, platforms such as Accella and SCOPE, a smart-city cloud-based open platform and ecosystem, offer the ability to integrate a variety of IoT systems into enterprise solutions.
These platforms provide APIs that IoT device developers can use to build new features and services. Increasingly, IoT developers are incorporating these APIs and demonstrating ease-of-integration into enterprise IT environments. The ThingSpeak API, for example, can be used to integrate IoT devices via HTTP communications. This enables organizations to capture data from their sensors, analyze that data, and then take action on that data. Similarly, AllJoyn is an open source project from the AllSeen Alliance. It is focused heavily on interoperability between IoT devices, even when the devices use different transport mechanisms. As IoT matures, disparate IoT components, protocols, and APIs will continue to be glued together to build powerful enterprise-wide systems. These trends beg the question of just how secure these systems will be.
The IoT connectivity layer is ripe with competition. There are many competing communication and messaging standards that can be used within an IoT system.
Both the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP) have a place in an IoT system. REST, for example, is TCP-based, and MQTT was designed to work with TCP. However, the need to support temporal and bandwidth constrained networks and devices has resulted in a move away from TCP and toward the use of the UDP. For example, MQTT-SN is a tailored version of MQTT that works with UDP. Other protocols such as CoAP are also designed to work well with UDP. Given the significant reliance on UDP at this layer, protocols such as Datagram Transport Layer Security (DTLS) exist as an alternative to Transport Layer Security (TLS), used for securing TCP communications.
IPv4 and IPv6 both play a role at various points within many IoT systems. Tailored protocol stacks such as IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) support the use of IPv6 in the network-constrained environments that many IoT devices operate within. Furthermore, 6LoWPan has been designed to support wireless internet connectivity at lower data rates for devices with very limited form factor.
In addition to this, 6LoWPAN builds upon the 802.15.4 Low Rate Wireless Personal Area Networks (LRWPAN) specification to create an adaptation layer that supports the use of IPv6. The adaptation layer provides features that include IPv6 and UDP header compression and support for fragmentation, allowing support for sensors in a variety of uses, including building automation and security. Using 6LoWPAN, designers can take advantage of the link encryption offered within IEEE 802.15.4 and can apply transport layer encryption, such as DTLS.
Radio Frequency (RF) protocols such as Bluetooth Low Energy (BLE), ZWave, and ZigBee support communication between IoT devices or with gateways that then use protocols such as LTE or Ethernet to communicate with the cloud. Tjensvold, Jan Magne, Comparison of the IEEE 802.11, 802.15.1, 802.15.4, and 802.15.6 wireless standards, September 18, 2007. URL https://janmagnet.files.wordpress.com/2008/07/comparison-ieee-802-standards.pdf.
In the energy industry, WirelessHART and Power Line Communication (PLC) technologies such as Insteon are used for device connectivity. PLCs are routed directly over existing power lines, enabling power-connected devices to be controlled and monitored—refer to http://www.eetimes.com/document.asp?doc_id=1279014. PLC is implemented in support of both home and industrial use cases.
IEEE 802.15.4 plays an important role as the physical and data link layer for other IoT protocols, including ZigBee, 6LoWPAN, WirelessHART, and Thread. Basically, 802.15.4 is designed to operate using either point-to-point or star topologies and is ideal for use in low-power or low-speed environments. Furthermore, 802.15.4 devices operate in the 915 MHz and 2.4 GHz frequency ranges, support data rates up to 250 kb/s and communication ranges of roughly 10 meters. The physical layer is responsible for managing RF network access, while the MAC layer is responsible for managing transmission and receipt of frames onto the data link.
ZWave supports the transmission of three frame types on a network—unicast, multicast, and broadcast. Unicast communications (that is, direct) are acknowledged by the receiver; however, neither multicast nor broadcast transmissions are acknowledged. ZWave networks consist of controllers and slaves. There are variants of each of these, of course. For example, there can be both primary and secondary controllers. Primary controllers are allowed to add and remove nodes form the network. ZWave operates at a frequency of 908.42 MHz (North America) and 868.42 MHz (Europe) with data rates of 100 kb/s over a range of about 30 meters.
Bluetooth/Bluetooth Smart also known as Bluetooth Low Energy (BLE) is an evolution of Bluetooth designed for enhanced battery life. Bluetooth Smart achieves its power-saving capability by defaulting to sleep mode and only waking when needed. Both operate in the 2.4 GHz frequency range. Bluetooth Smart implements high-rate frequency-hopping spread spectrum and supports AES encryption.
LTE—often referred to as 4G cellular—is a popular option for IoT connectivity. In a typical LTE network, User Equipment (UE) such as a smart phone (or an IoT device) contains a USIM that securely stores authentication information. The authentication information stored in the USIM enables authentication with the carrier's Authentication Center (AuC). A symmetric pre-shared key is provisioned to both the USIM (at manufacture time) and the AuC (at subscribe time), which then uses that symmetric key to derive an Access Security Management Entity (ASME). The ASME is used to derive additional keys that encrypt signalling and user communications.
Future 5G communications may offer additional deployment options for IoT systems, based on higher throughput and the ability to support many more connections. This may provide enhanced capabilities for direct connectivity of IoT devices to the cloud and allow for new centralized controller functions to be created that support multitudes of geographically dispersed sensors/actuators with limited infrastructure in place. More robust cellular capabilities will further enable the cloud to be the aggregation point for sensor data feeds, web service interactions, and interfaces to numerous enterprise applications.
There are many communication protocols used by IoT devices besides the ones discussed. The following is a description of some of those other protocols:
| Communication Protocol | Description |
| GPRS | All data and signals are encrypted using the GPRS Encryption Algorithm (GEA). SIM cards are used to store identities and keys. |
| GSM | A Time Division Multiple Access (TDMA)-based cellular technology. SIM cards are used to store identities and keys. |
| UMTS | Signaling and user data are encrypted using a 128-bit key and the KASUMI algorithm. |
| CDMA | Code Division Multiple Access cellular technology. No SIM cards are used. |
| Long Range Wide Area Network (LoRaWAN) | Supports data rates between 0.3 Kbps and 50 Kbps. LoRAWAN networks use three keys: A unique network key, unique application key for end-to-end security, and device-specific key. |
| 802.11 | Wi-Fi. Standard wireless technologies used in many environments. |
| 6LoWPAN | Low-power wireless Personal Area Network (PAN) designed to support automatic device network joining using a LoWPAN bootstrapping server to provision bootstrap information to 6LoPAN devices. A 6LoWPAN network includes an authentication server supporting mechanisms such as Extensible Authentication Protocol (EAP). Bootstrap server can also be configured with a device blacklist. |
| ZigBee | ZigBee uses 802.15.4 for the physical and Medium Access Control (MAC) layers. ZigBee networks can be configured in star, tree, and mesh topologies. ZigBee security services provide key establishment, key transport, frame protection, and device management. |
| Thread | Thread uses 802.15.4 for the physical and MAC layers. Supports connection of up to 250 devices within a network. Uses AES encryption. Uses a Password Authenticated Key Exchange (PAKE). New nodes join a network using a commissioner and DTLS to create a pairwise key that can be used to encrypt network parameters. |
| SigFox | Operates in the Ultra Narrow Band (UNB) in the 915 MHz (US) and 868 MHz (Europe) ranges. Devices sign messages with private keys. There is a limit of 140 messages per day per device, and SigFox supports anti-replay protections. |
| Near Field Communications (NFC) | Provide limited security protections. Often used in connection with another protocol. Short range support. |
| Wave 1609 | Prevalent in CV communications. Relies heavily on IEEE 1609.2 certificates that support attribute tagging. |
Protocols such as MQTT, the Constrained Application Protocol (CoAP), the Data Distribution Protocol (DDP), the Advanced Message Queuing Protocol (AMQP), and the Extensible Messaging and Presence Protocol (XMPP) run on top of lower-layer communication protocols and provide the ability for both clients and servers to efficiently agree on data to exchange. REST communications can also be run very effectively within many IoT systems. As of the time of writing, REST and MQTT are popular choices for IoT systems.
MQTT is a publish/subscribe model whereby clients subscribe to topics and maintain an always-on TCP connection to a message broker. As new messages are sent to the broker, they include the topic with the message, allowing the broker to determine which clients should receive the message. Messages are pushed to the clients through the always-on connection:
This model supports flexible communication use cases, allowing sensors to publish their data and brokers to pass that data onto subscribing systems that wish to consume or further process the sensor data. Although MQTT is primarily suited for use over TCP-based networks, the MQTT for Sensor Networks (MQTT-SN) specification provides an optimized version of MQTT for use within WSNs.
For more information, see Stanford-Clark and Linh Truong, MQTT for Sensor Networks protocol specification, Version 1.2. International Business Machines (IBM). 2013. URL: http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf.
MQTT-SN is optimized for use with battery-operated devices possessing limited processing and storage resources. It allows sensors and actuators to make use of the publish/subscribe model on top of ZigBee and similar RF protocol specifications.
CoAP is another IoT messaging protocol, UDP-based and intended for use in resource-constrained internet devices such as wireless sensor nodes. CoAP uses DTLS for security services. CoAP consists of a set of messages that map easily to HTTP: GET, POST, PUT, and DELETE:
CoAP device implementations communicate to web servers using specific Uniform Resource Indicators (URIs) to process commands. Examples of CoAP-enabled implementations include smart light switches in which the switch sends a command to change the behavior (state/color) of each light in the system.
XMPP is based on Extensible Markup Language (XML) and is an open technology for real-time communications. It evolved from the Jabber Instant Messaging (IM) protocol. Refer to http://www.ibm.com/developerworks/library/x-xmppintro/.
XMPP supports the transmission of XML messages over TCP transport, allowing IoT developers to efficiently implement service discovery and service advertisements.
XMPP-IoT is a tailored version of XMPP. Similar to human-to-human communication scenarios, XMPP-IoT communications begin with friend requests. For more information, see http://www.xmpp-iot.org/basics/being-friends/.
Upon confirmation of a friend request, the two IoT devices are able to communicate with each other, regardless of their domains. There also exist parent-child device relationships. Parent nodes within XMPP-IoT support configuration of trust policies that dictate what devices can connect with. Communication between IoT devices cannot proceed without a confirmed friend request between them.
DDS is a data bus used for integrating intelligent machines. Like MQTT, it also uses a publish/subscribe model for readers to subscribe to topics of interest:
DDS allows communications to happen in an anonymous and automated fashion, since no relationship between endpoints is required. DDS also supports Quality of Service (QoS) mechanisms. DDS is designed primarily for device-to-device communication and is used in diverse deployment scenarios, including wind farms, medical imaging systems, and asset tracking systems.
AMQP was designed to provide a queuing system in support of server-to-server communications. Applied to the IoT, it allows for both publish/subscribe and point-to-point based communications. AMQP IoT endpoints listen for messages on each queue. AMQP has been deployed in numerous sectors, such as transportation in which vehicle telemetry devices provide data to analytic systems for near-real-time processing.
Data collected from sensors may be stored as raw data at the edge and aggregated in storage within edge databases and the cloud. Data can exist in a variety of formats including text files, spreadsheets, log files, and of course in relational and NoSQL databases. Tools such as REST, WebSockets, XML, and JSON can be used for remote data acquisition. When designing the security architecture at this layer, consider how to validate the source of data, whether malicious data has been injected into data streams, and whether data has been tampered with at any point in the life cycle.
CSPs offer data services within their IoT service offerings. For example, AWS supports configuration of IoT devices to offload data to IoT-specific gateways. Data can also be ingested into AWS through platforms such as Kinesis or Kinesis Firehose. Kinesis Firehose, for example, can be used to collect and process large streams of data and forward on to other AWS infrastructure components for storage and analysis.
Once data has been collected within a CSP, logic rules can be set up to forward that data where most appropriate. Data can be sent for analysis, storage, or to be combined with other data from other devices and systems. Reasons for the analysis of IoT data run the gamut from wanting to understand trends in shopping patterns (for example, beacons) to predicting whether a machine will break down (predictive maintenance):
Software as a Service (SaaS) providers also offer analytic services for the IoT. For example, https://www.salesforce.com/in/?ir=1 has designed a tailored IoT analytic solution. Salesforce makes use of the Apache stack to connect devices to the cloud and analyze their large data streams. The Salesforce IoT cloud relies on the Apache Cassandra database, the Spark data-processing engine, Storm for data analysis, and Kafka for messaging.
An example of the immense data collection from IoT devices is the proliferation of small Unmanned Aerial Systems (sUAS)—or drones—that provide an aerial platform for deploying data-rich airborne sensors. Today, three-dimensional terrain mapping is performed by inexpensive drones that collect high-resolution images and associated metadata (location, camera information, and so on) and transfer it to powerful backend systems for photogrammetric processing and digital model generation. The processing of these datasets is too computationally intensive to perform directly on a drone that faces unavoidable size, weight, and power constraints. It must be done in backend systems and servers. These uses will continue to grow, especially as countries around the world safely integrate unmanned aircraft into their national airspace systems.
IoT devices generate mountains of data that must be captured, aggregated, and processed by analytic systems. Preprocessing of IoT-collected data often occurs at the edge, where an initial filter is applied leaving only filtered data to be passed to a data analytic system in the fog or in the cloud.
Preprocessing also includes the classification of data objects. Classification can be done based on the types and/or sensitivities of the data. Metadata is added, which includes tags that represent the security sensitivity and other attributes of the data or the sources that collected the data. For example, any sensitive data that requires confidentiality protections should be tagged as such. At this stage, both data and metadata should be digitally signed.
Data is cleaned and de-duplicated next. The cleansing process includes corrections that must be made based on bad data. Clean data is then input into data models where it can be produced into products and visualizations.
A key consideration within the data life cycle is the need for data lineage assurance. Data lineage tracks the origin of data and the transformations and actions that were applied to that data over time. Data lineage tools can visually represent data flows and movements across a system. There are a number of data lineage tools on the market today. Apache Falcon is an open source data lineage tool that can be applied to IoT systems. You can learn more about Apache Falcon here: https://falcon.apache.org/.
Applications hosted in the cloud or data centers provide features, reporting, and analytic functions for IoT systems. Applications can be consumer-facing, business-facing, industrial, health-care or municipal. Applications can also be management focused, providing the ability to control, monitor, and configure IoT devices, as in the following examples:
The architecture of IoT enterprise systems is relatively consistent across industries. Enterprise architects integrate solutions that include edge devices, gateways, applications, transports, cloud services, protocols, data analytics, and storage.
Indeed, some enterprises may find that they must utilize IoT capabilities typically found in other industries and served by new or unfamiliar technology providers. Consider a typical Fortune 500 company that may own both manufacturing and retail facilities. This company's business executives may consider deploying smart manufacturing systems, including sensors that track industrial equipment health status, robotics that perform various manufacturing functions, as well as sensors that provide data used to optimize the overall manufacturing process. Some of the deployed sensors may even be embedded right in their own products to add instrumentation and/or customer-engagement features.
This same company may also consider how to leverage the IoT to offer enhanced retail experiences to their customers, such as smart billboards integrated with vehicle infotainment systems to allow customized advertisements to consumers as they pass by a retail establishment.
That same company may require the ability to manage fleets of connected cars and shipping vehicles, drone systems that support the inspection of critical infrastructure and facilities, agricultural sensors that are embedded into the ground to provide feedback on soil quality, and even sensors embedded in concrete to provide feedback on the curing process at their construction sites.
This complexity introduces challenges to keeping the IoT secure and ensuring that particular instances of the IoT cannot be used as a pivoting point to attack other enterprise systems and applications. For this, organizations must employ the services of enterprise security architects who can look at the IoT from the big picture perspective. Security architects will need to be critically involved early in the design process to establish security requirements that must be tracked and followed through during the development and deployment of the enterprise IoT system.
It is much too expensive to attempt to integrate security later on. Enterprise security architects will select the infrastructure and backend system components that can easily scale to support not only the massive quantities of IoT-generated data, but also have the ability to make secure, actionable sense of all of that data.
The following diagram provides a representative view of a generic enterprise IoT system of systems and showcases the IoT's dynamic and diverse nature:
In this diagram we see energy IoT deployments connected to the cloud along with connected vehicle roadside equipment, health-care equipment, and environmental monitoring sensors. This is not accidental—as previously discussed, one principal feature of IoT is that anything can be connected to everything and everything to anything. It is perfectly conceivable that a health-care biosensor both connects to a hospital's monitoring and data analytic system and simultaneously communicates power consumption data to local and remote energy monitoring equipment and systems.
The growing number of points of connectivity across diverse systems increases the attack surface of an enterprise; therefore, IoT system interconnections must be thoroughly evaluated to understand the threats and required mitigations.
Data processing and analytic services are already gleaning valuable information from the volumes of data captured by IoT sensors. As the layer of IoT connectivity continues to expand, system designers will be able to incorporate new capabilities that better predict outcomes and failures and support machine-to-machine autonomous collaboration.
© 2018 Packt Publishing Limited All Rights Reserved
