LECTURE NOTES

Internet Of Things (IOT)

D5512 – Abba Suganda Girsang

Session 11

IOT Device Management

Code_Course – Name_Course
1. IOT Device Management Purposes

IoT device management is the process of authenticating, provisioning, configuring, monitoring

and maintaining the device firmware and software that provides its functional capabilities.
Effective device management is critical to establishing and maintaining the health, connectivity,
and security of IoT devices.

Effective IoT device management is a foundational element for any successful IoT solution. All
the major cloud providers include it in their IoT platform offerings. Whether it’s Google with IoT
Core, Microsoft with Azure IoT Hub, or Amazon with AWS IoT, their device management
offerings enable IoT solutions providers quickly and securely to provision, authenticate, configure,
control, monitor, and maintain the IoT devices used in their solutions.

Once an Internet of Things (IoT) device is installed, it is not a “fire and forget” scenario. There
will be bug fixes and software updates needed; some devices will fail and need to be repaired or
replaced; and each time this happens your company is on the hook to minimize downtime – not
only to keep your customers happy, but to ensure that you protect your revenue stream.

How do you ensure this? By designing thoughtful device management into your product. Any IoT
system must address four fundamental categories of device management, which are:

Provisioning and authentication. According to IDC, the number of Internet-connected devices

is expected to reach 30 billion by 2020. Many device manufacturers are largely inexperienced in
matters of security, and attacks from the hacking of Foscam security cameras to remotely attacking
connected Jeeps have already been widely publicized. Recently, Rob Joyce, the NSA’s lead
hacker, said the IoT is an excellent way to attack a target because devices provide a way of entering
a network that are often overlooked by sysadmins.

Configuration and control. Unless you are a glutton for punishment and want to preconfigure
every device you ship with the specifics as to where it will be installed and how it will be used,
you’ll be shipping a device with some sort of generic configuration. Most of the time, your device

Code_Course – Name_Course
will need to be further configured by the end user with attributes such as its name and location and
application-specific settings. In a fleet-management example, a device is used to track the location
and certain on-vehicle telemetry and report that information back to the cloud via a cellular
connection. Certain parameters will need to be written once the device is installed, such as the
unique ID of the trailer or truck (perhaps the license plate or VIN number). Other configuration
settings, such as the amount of time between sending position messages, are also determined and
programmed into the device. To implement certain control capability into a system, you’ll want to
remotely reset the device so as to achieve a known-good state and recover from errors and
implement new configuration changes. You may also want to be able reset the device to a factory
default configuration, which is useful when you want to decommission a device or as a more
invasive way to recover from unknown error conditions. Lastly, issuing a command to update or
reload firmware is very important in order maintain security of the remote device, implement
feature enhancements, and patch bugs. Device authentication is the act of securely establishing the
identity of the device to ensure that it can be trusted. A cloud-hosted service that the device
connects to needs to know that the device is actually a genuine device, is running trusted software,
and is working on the behalf of a trusted user.

Provisioning is the process of enrolling a device into the system. Authentication is part of that
process, where only devices that present the proper credentials are registered. The exact details of
this process can vary widely based on implementation. However, in most applications, the device
being deployed is loaded with a certificate or key (stored in a secure memory area) that identifies
it as authentic, and knows the server URL to connect to in order to enroll itself. When the device
is first plugged in and connected to the local network, it “calls home,” and then, based on the
credentials and other information such as the model and serial number of the device, it might
receive further configuration data.

Monitoring and diagnostics. In a system of thousands of remote devices, the smooth and secure
operation of each device can directly affect the financial bottom line. Small issues can impact
customer sentiment enough to hamper successful business outcomes. Monitoring and diagnostics
are vital to minimize the impact of any device downtime due to software bugs or other unforeseen
operational problems. As an example, you can detect when something is amiss by monitoring
compute, storage, networking, and I/O statistics at the task or process level, and comparing those

Code_Course – Name_Course
statistics to characterized nominal values. If the CPU utilization goes up to 60 percent in a process
that would normally consume 5 percent, then that gives troubleshooters another data point that
make identifying the bug much faster. Monitoring network statistics can also indicate possible
security breaches.

Being able to download program logs and dumps is also imperative to diagnosing and solving
software bugs. After all, you aren’t going to be able to travel to the devices to debug them in-
person with a serial terminal! The application developer must implement good program logging,
while device management software must make that information available for upload when an error
occurs. Taking that one step further, device management software might also use cloud-hosted
analytics software to provide useful insights into problems that occur across multiple connected
devices.

Software maintenance and update

You may not think so, but you will release software with bugs in it; you will want to add features
and functionality to it; and, yes, you will deploy devices with security vulnerabilities. Because this
is not key value-adding functionality, it is viewed as an afterthought (just like documentation!) to
most product developers, especially startup companies who are trying to get quickly to market.
However, this is one of the most important aspects of device management – it is absolutely
essential to securely update and maintain remote device software.

So, what does this mean? There are a lot of potential levels to software maintenance. On one level,
you must have a process to completely and securely update all the device software, including
bootloaders and binary blobs. You might use this to fix a security vulnerability that pervades the
platform firmware. To fix application bugs or add simple feature enhancements and save network
bandwidth, you may just want to update the main running application software without touching
the platform firmware.

Software maintenance in remote devices is a long-term, running process. You may not have a
persistent connection to a remote device if, for example, the device communicates via a wireless
connection. The link may not be reliable, especially if the device is moving, or if there is a
consumption cost involved in the data connection (for example, via cellular), then the link might

Code_Course – Name_Course
be established only periodically to save cost. Finally, one of the main reasons software updates are
complicated is that you need to perform them when there is minimal business impact.

Let’s go back to the fleet management example. Let’s say that you’ve had to make a change to the
software to fix a bug that just requires an update of the main task or application. Trucks travel
through pockets of persistent cellular connectivity, so they may not be on the network all the time.
In addition, you wouldn’t want to schedule the update while the truck was moving and giving you
the telemetry data that you need. You would schedule the update when the operator (in other words.
the truck driver) was resting and when it was reliably connected to the network.

2. Contetxtual IOT device Managament

While Basic IoT Device Management was once deprioritized by many IoT solution providers
(since such functionalities didn’t provide short-term differentiation for IoT solutions), as the IoT
industry continues to mature, these functionalities are becoming fundamental. All the major cloud
providers (Google, Microsoft, Amazon) now include Basic IoT Device Management as part of
their IoT offerings. Nonetheless, Basic IoT Device Management isn’t enough.

Device management originated within IT departments managing computing resources inside their
organizations. It evolved with the rise of mobile, which necessitated mobile device management
(MDM). Now, with the thousand to millions of devices within just a single IoT solution, new
challenges call for new approaches.

Past approaches to device management were built on the presumption of persistent and stable
device connectivity, often with relatively high bandwidth. For example, the Monitoring and
Diagnostics section above references monitoring CPU usage and downloading program logs from
devices to diagnose issues. However, with IoT, we’re seeing IoT solutions that can involve
thousands to millions of devices for which persistent connectivity and high bandwidth are far from
the norm.

IoT solutions can vary greatly depending on their application. Some of these IoT solutions do
involve high bandwidth and persistent connectivity but many don’t. Take agricultural IoT
applications as an example; you may have thousands of sensors (temperature, soil moisture,

Code_Course – Name_Course
sunlight, equipment asset trackers, etc.), in remote locations across an agricultural property. For
all of these sensors, long battery life becomes a critical functionality, because:

The devices aren’t going to be plugged into an electricity source in the middle of a field.

Replacing batteries frequently for thousands of devices would represent a massive operational (and
therefore financial) burden that would make a good return-on-investment (ROI) impossible.

However, there’s an inherent tradeoff between power consumption, bandwidth, and connectivity
range when it comes to network options. You can’t have them all. So if you want to ensure you
have the necessary range to cover broad fields in agriculture while maintaining long-lasting battery
life, you’re not going to get high bandwidth.

Low-Power Wide-Area Networks (LPWANs) are perfect for such use cases, with long range, low
bandwidth, and extensive battery life. And for many IoT applications, this low bandwidth isn’t a
problem. For example, a temperature sensor may only need to report temperature (representing
very little data) a few times per hour (representing low frequency).

What many don’t realize about LPWANs is that by their very nature (low bandwidth), Basic IoT
Device Management may be insufficient to identify and diagnose issues. In these LPWAN
applications, messages from devices are fire-and-forget — devices aren’t always “listening” for
new messages. “Listening” takes battery life. For IoT applications in which battery life is critical,
this means that the devices will only “listen” for new messages coming back to them at set time
intervals (e.g. once every 12 hours). Contrast this with your smartphone, which is constantly
“listening” to check if there are new messages. What many don’t realize is that this means that in
many IoT applications, you can’t “ask” a device if it’s ok.

If you stop hearing from an IoT device, is it because there’s an issue with the device (e.g. a
hardware defect or a firmware bug)? Or is it because the device just didn’t have network
connectivity the last time it tried sending you a message? Or maybe enough devices tried
communicating at the exact same time that some of the messages collided (this can happen with
radio waves) and therefore didn’t get through? Or perhaps the device’s battery is simply dead?

Code_Course – Name_Course
Without Contextual IoT Device Management, managing thousands to millions of devices, for
which you have very little data, can quickly become an operational nightmare that can eliminate
any hopes at a good ROI and kill an IoT solution.

3. Security issues in IOT Management

IoT security management must be approached in new ways, moving from reactive and manual to
proactive and automated. The sheer volume of devices that will get connected calls for security
automation, and enhanced security analytics capabilities.

There are some issues in IOT Security to think. They are :

Trusted identities. As the number of connected devices grow, identifying each device becomes
increasingly important, and complex. Device identification is done on the connectivity or
application level. SIM, and the evolution to embedded SIM's (eSIMs), provide good protection of
the device connectivity identity. For device identification on application level, certificates are
commonly used. Identity and Access Management (IAM) systems verify the identity of a device a
Mobility is the key to new services and enabling new revenue streams. That means digital identity
solutions across mobile, federated or IAM cloudbased platforms are crucial for individuals and
services. Why? Because they counter-act the growing issue of identity exposure and unexpected
digital threats. When it comes to personalized services, issues of identity validation, consent,
attribute sharing, and trust management really matter. This need for resilient, advanced IAM spans
across IoT devices, individuals and services, from internet banking to smart metering. Some may
need more security than others: internet banking, for example, will need the highest security multi-
factor authentication (MFA), consent and authorization. With many IoT devices' service life
spanning decades, having the right mix of algorithms and key sizes for the authentication,
authorization and encryption protocols is a must. nd what data it has access to.

Trusted connectivity. Network availability and reliability are important security objectives for
IoT systems. With ICT infrastructure under constant attack, traffic separation and protection
technologies reduce the risk of costly downtime and denial-of-service (DoS). Traffic separation
methods, including the 5G network slicing concept, will provide isolation of network, application
and security functions, allowing service providers to offer different security levels for different

Code_Course – Name_Course
network slices. Transport Layer Security (TLS) and Internet Protocol Security (IPSec) encrypt
data to ensure traffic protection.

Trusted data. In an IoT where many decisions are data-driven, it is crucial to ensure that each
device is behaving as it should, and its data has not been manipulated. Breaches need to be detected
as quickly as possible to limit possible damage. Data needs to be protected in transit, and 3GPP
networks support security controls to preserve data integrity, confidentiality and availability to
guarantee the security and privacy of the information.

Privacy and confidentiality. Respecting the right to personal data protection is increasingly
difficult, as personal information can be drawn from analyzing IoT device data. The pressure to
protect and anonymize data increases with the enactment of Europe's GDPR. Non-compliance
could have serious consequences for the bottom line of any company operating in the EU.

We know that cyber security management is a challenge already today and the challenges will
increase when networks become more dynamic with virtualization, 5G and IoT. With such big
changes comes greater risk for attacks. Systems are becoming more exposed, with new threats
appearing from every angle. For service providers, concerns include the risks associated with
decentralization, virtualization and critical infrastructure, as well as increases in fraud.

To minimize the impact of these risks, organizations need to shift how they manage security.
Moving from a manual, reactive approach to one that is automated, policy-based and intelligent.
There is a need for a solution that constantly monitors security compliance, detects and responds
to new threats, supporting cost-efficient security operations.

4. Lightweight M2M (LWM2M)

Open Mobile Alliance (OMA) Lightweight M2M is a protocol from the Open Mobile Alliance
for M2M or IoT device management. Lightweight M2M enabler defines the application layer
communication protocol between a LwM2M Server and a LwM2M Client, which is located in a
LwM2M Device. The OMA Lightweight M2M enabler includes device management and service
enablement for LwM2M Devices. The target LwM2M Devices for this enabler are mainly
resource-constrained devices. Therefore, this enabler makes use of a light and compact protocol

Code_Course – Name_Course
as well as an efficient resource data model. It provides a choice for the M2M Service Provider to
deploy a M2M system to provide service to the M2M User. It is frequently used with CoAP.

OMA Lightweight M2M is designed to:

 Provide Device Management functionality over sensor or cellular networks

 Transfer service data from the network to devices
 Extend to meet the requirements of most any application

Lightweight M2M 1.0 enabler introduces the following features below for the initial release.

 Simple Object based resource model

 Resource operations of creation/retrieval/update/deletion/configuration of attribute
 Resource observation/notification
 TLV/JSON/Plain Text/Opaque data format support
 UDP and SMS transport layer support
 DTLS based security
 Queue mode for NAT/Firewall environment
 Multiple LwM2M Server support
 Basic M2M functionalities: LwM2M Server, Access Control, Device, Connectivity,
Firmware Update, Location, Connectivity Statistics

Code_Course – Name_Course