oa Internet of Things Security: We're Walking on Eggshells!

Since the Internet of Things (IoT) will be entwined with everything we use in our daily life, the consequence of security flaws escalates. Smart objects will govern most of the home appliances and car engines yielding potential disaster scenarios. In this context, successful attacks could lead to chaos and scary scenarios (www.darkreading.com). Unprotected personal information may expose sensitive and embarrassing data to the public and attacks may threaten not only our computers and smart devices, but our intimacy and perhaps our lives too.

Because persons and objects will be bonded with each other, user consent becomes critical. Therefore, thing, object, and user Identity will be the focus of future IoT security solutions, yielding a Trust, Security, and Privacy (TSP) paradigm, which may constitute the Achilles' heel of IoT.

While security issues are quite straightforward, mainly from background knowledge, privacy issues are far more complex. Privacy constitutes a rather challenging task, even for the most skilled developer and may impede large scale deployment of IoT. Vinton Cerf stated that “Privacy may actually be an anomaly”, generating a whole lot of discussions among Internet users. And as Scott McNealy further pointed out nearly a decade ago: “You have zero privacy anyway. Get over it!”

From an industry and developer perspective, privacy is a matter of user conduct and responsibility. Consumers need to be trained to understand that by saving their personal data on various devices, they expose themselves to various types of attacks. Often, there is no mean for users to know whether their personal data is being tracked or “stolen” by third parties.

In fact, technology seems to have evolved far beyond any expectations and we seem not prepared to deal with it. As Vinton Cerf also pointed out that “figuring out how to make a security system work well that doesn't require the consumer to be an expert is a pretty big challenge.” For instance, consumers often use easy to remember and similar passwords as well as USB Flash drives in various systems, rendering the development of secure solutions as digging holes in water.

With the advent of IoT, manufacturers of “traditional” home appliances, construction, and industrial engines will be required to include communication components to their products. As these components will be subject to the same cyber threats as computers and smart phones, manufacturers will also need to integrate security into their manufacturing processes, from the design phase to packaging.

There are quite a number of IoT architectures emanating from mainstream standards bodies. In what follows we describe and discuss some of the most promising architectures namely from IETF, ITU-T, ISO/IEC, IEEE, ETSI, and oneM2M.

IETF's Security Architectures

As for the common Internet, the IETF is playing a lead role in IoT standardization efforts. A variety of proposals are being made, ranging from application layer to network layer protocols; and from sensor networks to RFID communications.

IETF Core Architecture

According the IETF, “a security architecture involves, beyond the basic protocols, many different aspects such as key management and the management of evolving security responsibilities of entities during the lifecycle of a thing.” The proposed IoT security architecture aims to be flexible by incorporating the properties of a centralized architecture whilst at the same time allowing devices to be paired together initially, without the need for a trusted third party.

Some key new security features that go beyond current IT paradigms are to take into account the lifecycle of a thing. To this regard, a thing may need to go through various stages during its lifecycle: Manufactured, Installed, Commissioned, Running, Updated, Reconfigured, etc.). In the manufacturing and installation phases, the thing is Bootstrapped, while during the commissioning and running phases, the thing is Operational. In each stage, security credentials and ownership information may need to be updated.

The architecture also takes into account the specific features of IoT devices namely, low processing power, low energy resources, and potential inaccessibility. Further, things may need to be protected for decades and need to be reset to rebuild security capabilities over time.

Further, the IETF proposes an architecture that describes implementation and operational challenges associated with securing the streamlined Constrained Application Protocol (CoAP, RFC 7252). The draft also proposes a security model for Machine to Machine (M2M) environments that requires minimal configuration. The architecture relies on self-generated secure identities, similar to Cryptographically Generated Addresses (CGAs) (RFC3972) or Host Identity Tags (HITs) (RFC5201).

DTLS-based Security Architecture

Datagram Transport Layer Security (DTLS, RFC 6347) is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security features, but uses datagram semantics. The IETF introduces a full two-way authentication security scheme for IoT based on DTLS, which is designed to work over standard protocol stacks namely UDP/IPv6 over Low power Wireless Personal Area Networks (6LoWPANs, RFC 4944).

HIP support for RFIDs

In order to enforce privacy, an architecture based on the Host Identity Protocol (HIP, RFC 5201) for active RFID systems that supports tamper resistant computing resources is proposed.

The HIP-RFID architecture includes three functional entities: HIP RFIDs, RFID readers, and portals. The architecture defines a new HIP Encapsulation Protocol (HEP). The architecture also defines an identity layer for RFID systems that is logically independent from the transport facilities. HIP-RFID devices hide the identity (typically an EPC-Code) by a particular equation that can be solved only by the portal. Messages exchanged between HIP-RFIDs and portals are transported by IP packets.

ETSI M2M Architecture

The ETSI M2M architecture describes a range of variants that depend on the security characteristics of the underlying networks and on the relationships between the M2M service provider and the network operator.

The ETSI TS 102 690 Technical Specification (TS) describes a functional architecture, including the related reference points and the service capabilities, identifiers, information model, procedures for bootstrapping, security, management, charging, and M2M communications implementation guidance. The M2M functional architecture is designed to make use of IP based networks, typically provided by 3GPP as well as the Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) environment.

Among other things, the ETSI TS 102 690 TS introduces an M2M security framework for underlying functions and related key hierarchy. It is worth noting that the ETSI 103 104 specification describes an “Interoperability Test Specification for CoAP Binding of ETSI M2M Primitives”, which is of a particular importance in terms of interoperability with IETF standards.

OneM2M Security Architecture

The oneM2M standardization body emerged as a unified effort of standards organizations namely, ETSI, ATIS (Alliance for Telecommunications Industry Solutions), TIA (Telecommunications Industry Association), CCSA (China Communications Standards Association), TTA (Telecommunications Technology Association of Korea), ARIB (Association of Radio Industries and Businesses) and TTC (Telecommunication Technology Committee) from Japan. oneM2M aims to “unify the Global M2M Community, by enabling the federation and interoperability of M2M systems, across multiple networks and topologies”.

ITU-T Architectural Framework

The ITU-T is actively working on standardizing IoT security. For this purpose, a large number of recommendations were published or being considered. In particular, recommendation ITU-T Y.2060 provides an overview of IoT and clarifies the concept and scope of IoT. It further identifies fundamental characteristics and high-level requirements of IoT. What is important to note is that security and privacy are assumed to be de facto features of IoT within ITU-T standards.

ITU-T SG17 is currently working on cybersecurity; security management, architectures, and frameworks; identity management; and protection of personal information. Further, security of applications and services for IoT, smart grid, Smartphones, web services, social networks, cloud computing, mobile financial systems, IPTV, and telebiometrics are also being studied.

In particular, ITU-T rec. X.1311 provides a security model for Ubiquitous Sensor Networks (USN). Note that this model is common with ISO/IEC 29180 and based on ISO/IEC 15408-1 (see below). In the presence of a threat, appropriate security policies will be selected and security techniques will be applied to achieve the security objective.

Further, rec. X.1312 provides USN middleware security guidelines, while security requirements for routing and ubiquitous networking are provided in Rec. X.1313 and X.1314, respectively.

In addition, ITU-T is actively working on tag based identification through a series of recommendations such as ITU-T rec. F.771, rec. X.672, and rec. X.660. In particular, rec. X.1171 deals with Threats and Requirements for Protection of Personally Identifiable Information in Applications using Tag-based Identification.

ISO/IEC Reference Architecture

The ISO/IEC NP 19654 IoT draft std. introduces a Reference Architecture as a “generalized system-level architecture of IoT Systems that share common domains”. Developers may use parts or all these domains and entities. The IoT RA also aims to provide rules, guidance, and policies for building a specific IoT system's architecture. The IoT RA includes three key enabling technology areas:

1. IoT system of interest;

2. communications technology; and

3. information technology.

The IoT RA standard describes a conceptual model where seven IoT System Domains are defined: 1) IoT System, 2) Sensing Device, 3) Things/Objects, 4) Control/Operation, 5) Service Provider, 6) Customers, and 7) Markets.

The ISO/IEC 29180 std. (which is common with ITU-T rec. X.1311 described above) describes security threats to and security requirements of USN. The std. also categorizes security technologies according to the security functions.

On the other hand, ISO/IEC 29167-1 deals with security services for RFID air interfaces. This standard defines a security service architecture for the ISO/IEC 18000 RFID standards. It provides a common technical specification of security services for RFID devices that may be used to develop secure RFID applications. In particular, the std. specifies an architecture for intractability, security services, and file management.

Moreover, the ISO/IEC 24767 standard specifies a home network security protocol for equipment that cannot support standard Internet security protocols such as IPSec or SSL/TLS. This protocol is referred to as Secure Communication Protocol for Middleware (SCPM).

European Internet of Things Architecture (IoT-A)

A Reference Model and a Reference Architecture are introduced by IoT-A, both providing a description of greater abstraction than what is inherent to actual systems and applications. The RM is composed of several sub-models. The primary model is the IoT Domain Model, which describes all the concepts that are relevant to IoT. Other models include the IoT Communication model and the Trust, Security, and Privacy (TSP) Model.

The TSP model introduces interaction and interdependencies between these three components. The IoT-A model focuses on Trust at the application level providing data integrity, confidentiality, authentication, and non-repudiation.

In turn, the security RM proposed by IoT-A is composed of three layers: the Service Security layer, the Communication Security layer, and the Application Security layer. One of the key aspects is that while taking into account heterogeneity, tradeoffs between security features, bandwidth, power consumption, and processing are of a major concern in IoT-A.

Conclusion

The need for a Reference Model and a Reference Architecture seems to have reached a global consensus. However, because this concept is quite abstract, we need more pragmatic definitions that give developers straightforward guidelines in their endeavour to develop secure IoT services and applications.

Technologies like Zigbee, KNX, Z-Wave, BACNet are quite mature and much more secure than 6LoWPAN. Users who invested in those mature technologies may not be willing to switch to another technology any time soon. This was also the case for other networking areas where IP may be used for entertainment, education, and research but cannot be trusted for transactional applications, business critical applications, and sensitive applications requiring high reliability and security.

Further, the advantages brought by 6LowPAN over Zigbee are not significant: they both use the 802.15.4 PHY and MAC layers. Zigbee uses its own high layer stack while 6LowPAN is based on compressed IPv6 headers. Further, 6LowPAN requires an adaptation layer and supports fragmentation, a feature that may be cumbersome given the required simplicity of constrained low-resource environments.

ITU-T, IEEE, IETF, ETSI, and ISO/IEC seem to be heading towards a common security architecture although the picture is not clear yet. The oneM2M initiative is one step towards this goal. Other initiatives are needed where pragmatic definitions will be of a much greater help for developers.