M2M And The Internet Of Things

Securing the Internet of Things/Everything (IoT/E) is a bit like herding cats. There are so many elements that will make up the IoT/E, it may seem an insurmountable objective to corral them all into a single stable. By some accounts, we’re on our way toward 200 billion Internet-connected machines by 2020, according to IDC. Soon we will live in a world where automated machine-to-machine (M2M) transactions will outnumber traditional human-to-computer transactions by an order of magnitude.

In previous articles, we have discussed things such as code vulnerabilities, securing wireless interconnect and securing the objects of the IoT/E. In this installment, we’ll will take a look at how machine-to-machine (M2M) objects will integrate into the IoT/E and what unique security issues they have.

In the beginning…
M2M, as a standalone technology, came into existence about the same time as did computer networking automation. In the early years, it was relegated to applications such as telemetry, industrial automation, supervisory control and data acquisition (SCADA), and similar low-level, data interchange applications.

It started to come into its own in the mid-1990s when the cellular infrastructure added a new option for it – using cellular radio frequencies, rather than the industrial, scientific, medical (ISM) bands, for the M2M communications links. Armed with this new spectrum, more and more M2M modules started to appear. They were also finding their way into a wider range of applications such as remote monitoring and tracking applications, remote sensors, point-of-sale (POS) terminals, vehicle telematics, farm watering systems, and more.

By the end of that decade, M2M wireless technology had become relatively complex, reliable, and ruggedized. It was now being developed for a variety of additional vertical markets and showed steady growth to where today, M2M data modules are extremely sophisticated and available with a wide range of advanced features and capabilities.

Systems exist with such state-of-the-art technologies such as global positioning systems (GPS), flexible land grid-array surface mounting, embedded M2M optimized smart cards (similar to phone SIMs) known as M2M identification modules (MIMs) and intrusion systems. Other market segments include banking, consumer electronics, healthcare, home automation, the military, and more.

The pièce de résistance for modern M2M systems is Java operability — one of the key attributes that makes them so attractive to IoT/E developers. But that’s also one of the chief concerns for IoT/E object security. (This is discussed more deeply, later in this article.)

Overall, this evolution of embedded objects has made them the perfect objects to interface the multitude of devices that will need autonomous communications as the IoT/E unfolds.

M2M as embedded systems
Peel back the layers, and the naked truth is that M2M modules are just one form of embedded systems, and share the same issues as other embedded systems. Because not everyone is intimately familiar with what an embedded system is, a M2M 101 crash course might be worth a quick read.

Embedded systems and devices differ from open systems such as personal computers, smart phones and tablets.. Figure 1 is a generic block diagram of how an embedded system might be configured.

Fig. 1: Typical block diagram of an embedded system. (Courtesy of National Instruments)

While these open systems may have embedded components, they are not the fixed hardware devices that are defined as true embedded objects. These types of systems are designed to have the components accessible and modifiable — some easier than others, but accessible nonetheless. They can have their “intelligence” modified by any number of peripheral I/O devices (mice, keyboards, touch screens, OS upgrades, etc.), and can have their hardware modified as well (RAM, ROM, drives, and E/EEPROM reprogramming).

Embedded systems are, for all intents and purposes, eternally sealed from the hands of man and machine. They have a completely different level of architecture, complexity, and computational capability. And they are not “upgradable” in the traditional sense.

The single, most definable, feature is that the OS resides in a permanent image in ROM. It cannot be modified and is defined for the particular purpose of the M2M module. There are, of course, exceptions to this generalization as there are to almost all technological structures, but generally, this is the design criterion for smart embedded devices.

What connects M2M and embedded systems is the autonomous communications between embedded controllers. All it takes is a wireless link, Ethernet port, serial controller or other peer-to-peer connection, and the devices can communicate without any external, user, or device dependency – that is from where the term machine-to-machine is derived.

Overall, M2M devices are connected to virtually all peripheral platforms. They are the ideal data exchange medium for objects of the IoT/E, but they also can be used to interface mobile, cellular and RF systems, server, Web, and cloud services, and other embedded systems. They are the automated exchange of telemetry, operational, and other command and control information between machines, across all platforms. This means they also can be the ideal vehicles for security breaches across, and within these same platforms.

Compromising the game
No matter what type of embedded system M2M, IoT/E, SCADA, command and control, they all have similar security concerns. Autonomous M2M and IoT/E have somewhat different attack methodology than open systems because they cannot have rational awareness of compromises, so the defenses must also be different.

“Whether it’s ‘the Internet of things’ the consumer world, or the M2M industrial counterpart, there are some unique issues with securing autonomous smart devices,” said Santiago Pontiroli, security researcher at Kaspersky Labs. “Because they are hyper-connected it opens numerous entry points for attackers. Given the importance of the information these M2M devices handle, they will become a desired target that will need to be protected around the clock.”

It gets worse. “The lack of protocol standardization, the indistinct usage of wired of wireless networks and the presence of a true heterogeneous environment makes centralized management and security policy compliance a daunting task,” Pontiroli said. “Not only do we have a plethora of different devices living together (perhaps each from a different vendor), we also have each device built using microcontrollers from different manufacturers, implementing the features they deem necessary, while disregarding interoperability and security standards.”

He’s not alone in sounding the warning bell, either. “A typical IoT gadget has the connectivity and security capabilities of a Windows 95 PC, but runs connected to the modern Internet,” said Benjamin Jun, vice president and CTO of Cryptography Research at Rambus. “These devices are built with smaller security budgets, are rarely (if ever) updated or managed, and run on embedded platforms with fewer protections than Windows 95. All of these changes place new and different security pressures on IoT devices.”

Jun stressed that “defense in depth, or layered defense measures,” should be part of the architectural phase in design. “There is always the option of rejecting a device if the vendor doesn’t comply with essential security standards or company policies. If there is no other option than to get a specific device that has known issues, containment measures need to be implemented that will limit the exposure of a probable incident.”

We have a long way to go before we can feel comfortable that M2M devices will have a parallel security level that their open systems counterparts have reached. That being said, discussion on the types of attacks that M2M devices are likely to see follows.

Currently, there are six general categories for M2M device attacks. They are:

1. Physical. This can include insertion of valid authentication tokens into a manipulated device, inserting and/or booting with fraudulent or modified software (“re-flashing”), and environmental/side-channel attacks, both before and after in-field deployment.
2. Configuration attacks. These are made up of such components as fraudulent software update/configuration changes, capitalization on misconfiguration by the subscriber or user and compromise of the access control lists.
3. Attacks on the core network. These are threats to the mobile network operator (MNO). They can come in the form of impersonation of devices, traffic tunneling between impersonated devices, misconfiguration of firewalls in modems/routers/gateways, denial-of-service (DoS) attacks against the core network. One particularly nasty one will change the device’s authorized physical location in attacks on the radio access network, using a rogue device.
4. Protocol attacks on the device. These are directed against the physical device itself. These consist of such things a man-in-the-middle attacks upon first network access, DoS attacks, compromising a device by exploiting weaknesses of active network services, and attacks on operations/administration/management (OAM) and its traffic.
5. User data and identity privacy attacks. These include eavesdropping for other user or device data sent over the regular or evolved UMTS terrestrial radio access network (UTRAN/E-UTRAN). They can masquerade as another user or subscriber’s device, a user’s network ID, or other confidential data revealed to unauthorized third parties.
6. Compromising of credentials. This approach brings brute force attacks on tokens and (weak) authentication algorithms, physical intrusion, or side-channel attacks, as well as malicious cloning of authentication tokens residing on the machine communication identity module (MCIM).

Within these categories, there are a number of methodologies that attackers use for M2M systems, and some from outside that are worth mentioning as well. They include:

• Obtaining particular device hardware and/or documentation for reverse engineering.
• Reverse-engineered firmware for passwords, keys, system configuration, and anti-tamper protection.
• Obtaining existing research on known usage, maintenance, and security vulnerabilities.
• Obtaining OS platforms, codes EDA libraries.
• Acquiring firmware images and reverse engineering them.
• Using probes to run services/protocols.
• Using probes to dump ROM and other non-volatile memory for keys and data.
• Accessing devices as a proxy or impersonating device calls or other devices.
• Probing for weaknesses.
• Monitoring communications protocols and data packets.
• Compromising update mechanisms and fool device with bogus update.
• Attempting to identify security protocols and breach.
• Physically disassembling and probing to obtain device component identification.
• Physically decomposing MCUs to capture data.

The fact that there are so many avenues of attack is certainly something that designers of M2M hardware for the IoT/E are keenly aware of. One thing Jun mentioned is a theme that resounds with virtually all security-conscious entities: “Security-aware communication is key. SoC designers and verification teams are involved early in the process and are often the first to recognize when security requirements are incomplete or inconsistent.”

It’s best to bring security into workflows, use cases, and software stack discussions very early on. Seek qualified help when you need it. Many bugs have been created by people without the proper background, often while trying to reinvent the wheel.

The most effective way to thwart these is to encapsulate the objects with an end-to-end security blanket. That is often not as simple as it sounds because, as was just discussed, there are many vectors from which an attack can come, including wireless, wired and backend servers. So, implementing countermeasures is no simple task. However, the industry is, slowly, waking to the reality check that threats exist at all levels, and it is time to put the security pedal to the metal.

Countermeasures
In spite of this seemingly insurmountable challenge of attack vectors, and the security mindset, M2M countermeasures are gaining traction. Today, there exists a decent crop of options in the developer’s toolbox.

“However, it’s tricky to add security to constrained devices,” Jun said. “One cost-effective approach is to manage critical functions with an on-die security core. When system components can be built with less trust, designers can reduce the costs of developing secure software, and use commodity external components with fewer security characteristics.”

System-level cores are an excellent tool to constrain costs and provide a level of security to the object, irrespective of the platform on which they will function. Integrating them with interconnect platforms, such as either RF or Ethernet, or backend solutions, each with their own security layers, provides a somewhat more bulletproof object.

There are two general classes of countermeasures, passive and reactive. Passive measures generally are limited to removing vulnerabilities that would allow a hacker to encroach the system. Such methodologies do not prevent attacks, but they do limit the reaction of the device to it. Passive measures can include the backend system ignoring suspicious commands or questionable data from the device. The device itself can cease operations if requests or commands are out of the accepted queries, or simply ignore incoming commands to it. Passive options include:

• Restricted access, allowing only essential services and only to the essential channels (for example, disable SMS if not a function of the application).
• Keeping the access point name (APN) and information confidential. If it must be transmitted, use secure channels.
• Restricted access to Mobile Subscriber Integrated Services Digital Network Numbers (MSISDNs) to a specifically defined range,
• Preventing the exchange of IDs and passwords via unsecure channels.
• Using fixed IP addresses or URLs within the M2M application software, and using secure channels to transmit IP addresses to the M2M application.

Reactive measures are a much stronger approach to device compromise. They use approaches such as: spectrum scanning for unusual activity or behavior; implementation of digital signatures on data messages between the mobile device and the M2M server to detect faked messages; correlated GPS location information (e.g. cell-IDs) and timestamps to verify the received positioning data in the backend system. Also on the list are implementing plausibility checks within the M2M backend system to detect manipulated data, use of keep-alive notifications from M2M devices, or the network to monitor connection, and implementing tamper alerts in the hardware design to trigger an M2M server notification.

Reactive measures generally are applied to the more at-risk devices, such as those with ubiquitous access to Internet protocols (as opposed to local cells) where attack vectors can come from a variety of directions. Passive measures are much cheaper to implement and attractive to inexpensive autonomous objects. They are also easier and simpler to apply across entire systems or networks.

Finally, what will be the biggest enabler of IoT/E and M2M devices will also turn out to be its greatest vulnerability – Java.

The wild card: Java
Java is a well-understood, minimalistic object oriented (OOP) programming language, that developed by Sun Microsystems (now owned by Oracle). It has the look and feel of C++ but is much simpler and compact. Since 2006, it has been generally free and open software, much like UNIX.

Its attributes as a programming language are that it is concurrent, class-based, object-oriented, and specifically designed to have as few implementation dependencies as possible. It is designed to allow application developers to create “write once, run anywhere” (WORA), code – code that can run on various platforms without recompiling.

Java applications are typically compiled to bytecode (class file), which can run on any Java virtual machine (JVM) regardless of computer architecture. This ubiquity of applicability makes it an extremely attractive arena for hackers to play around in. Given all of these golden attributes, one can easily see how IoT/E and M2M devices with Java enabled can be compromised.

To protect devices that run Java, there must be tight, active security measures in place. Java does have a security platform called Java SE. This is a set of APIs, tools, and implementations of commonly used security algorithms, mechanisms, and protocols. The security APIs including cryptography, public key infrastructure, secure communication, authentication, and access control. Appendix A presents a table of features for reference (courtesy Sun Microsystems).

For IoT/E devices that would use cellular communications protocols as an example, the strongest countermeasure is to implement the java security framework module for cellular communications. This module includes such elements as strong authentication, encrypted communication and secure over-the-air (OTA) updates to applications. It also has the ability to implement data signing, ensuring data integrity, and authenticity, pairing the MIM with a specific M2M device and locking the connection. It also separately can store the sensitive data within the M2M device in a secure element.

The above Java discussion has just touched on some of the countermeasures that are available and could be implemented to secure objects of the IoT/E. As is repeated over and over, the IoT/E is still kind of a hazy, undefined blob. But no matter how it shakes out, much of what is already out there will be the initial objects of the current Internet. So there is a model from which to evolve. The unknown is the integration, on a large scale, of autonomous smart objects with mass integration across numerous platforms. And, at least one platform is emerging that may lay some groundwork for standardizing these objects. It is called a trusted platform.

Trusted platforms
One the best practices that seems to be emerging is to establish trust relationships in dispersed systems, such as the IoT/E. Trust relationships can be oblivious to platforms and objects because the interconnect relationship is accepted by the trusted platform and assumes whatever passes between them is safe, hence the term trusted platform.

Trusted platforms integrate security-relevant elements and capabilities, which form the building blocks of the trust boundaries. This includes methods to extend trust boundaries to external entities as well.

A trusted environment (TRE) is a logically isolated component within the M2M device. It is separated from the M2M device hardware. It encompasses all required functions and resources to be able to execute software and store sensitive data in a trustworthy space. It also can contain what is called a hardware security trust anchor – a hardware-secured tamper resistant mechanism. Figure 2 is a block diagram of a typical M2M device integrating a trusted platform.

The heart of this system is referred to as the root of trust (RoT). The RoT is responsible for securing the internal workings of the system and presenting the properties of the system identity to the external entity. The RoT also protects the TRE during startup. It ensures that all of the components required to start the device are secure and, upon validation, extends that security to the OS and any applications or software. If everything checks out, the RoT considers the device secure and extends the trust boundary to the entire object. Once this level is reached, then the object can function autonomously, with a high degree of security.

Fig. 2: A block diagram of a typical M2M device integrating a trusted platform.

How all this is done is extremely detailed and best left to another discussion. But the bottom line is that a world of autonomous objects connected via a new order of the Web will require a much higher autonomous level of trust. TREs are a novel approach to that end.

Conclusion
In a world where self-aware, intelligent autonomous objects outnumber their human counterparts by as much as an order or two of magnitude, making sure these objects are secure is the top priority for developers. As economies of scale loom large in an extremely competitive 21st century, security isn’t always at the top of the feature set. This is especially true because there is little, if any, ROI from it, so there is a strong temptation to reduce the investment.

However, we stand at a crossroads. We have intrinsic knowledge of the ramifications if we don’t make security a priority. So, will we?

Appendix A: Jave SE security platform (courtesy of Sun Microsystems/Oracle)