The IPSO Alliance is pleased to share this blog from member company Greenwave System’s Mark Baugher, who participates in our Security, Privacy and Identity working group. In this blog, Mark offers an easy-to-understand look at the issues that need to be considered related to IoT security and the challenges of doing so, as well as his thoughts on what the future might look like.

IoT Security: End-to-End and Hop-to-Hop
Mark Baugher, Greenwave Systems

What if you say “unlock my front door” to Amazon Alexa or Google Voice or Apple Siri? We wouldn’t want just anyone to unlock doors, clear alarms or control devices by yelling commands through a window. Some controls on access are needed.

But without end-to-end security, someone might gain access to your IoT commands, responses, notifications and other data at points in-between the endpoints. Figure 1 is how it should work.

End-to-End Security


Figure 1: End-to-End Security in an IoT service without middleboxes

The IoT user interface (UI) on the right side of Figure 1 uses a TLS connection to an IoT device such as an alarm, lighting system or thermostat. This network security is end-to-end: Data are in the clear only at source and destination endpoints; endpoints can verify the data origin and destination. This is end-to-end network security between exactly two devices.

There is often a need, however, to add a gateway, border router, message router or cloud server to the service. As shown in Fig. 2. Some IoT gateways need to terminate and originate communications on their interfaces [1] for various purposes: Z-Wave, Zigbee and other non-IP IoT networks, for example, need an IP gateway to reach the IoT UI. Or the device runs IPv6 and the UI is on an IPv4 network. A third case is when a cloud gateway serves as an interface to backend servers. An IPv6-to-IPv4 gateway is depicted in Figure 2. Zigbee and Z-wave don’t use TLS but run custom security protocols.

Hop-by-Hop IoT service through an IoT gateway

Figure 2: Hop-by-Hop IoT service through an IoT gateway

Gateways and other IoT “middleboxes” get access to information that they do not need and should not have. This article describes work on this problem, starting with hop-by-hop security.

Hop-by-Hop Security

There are risks and often a need for a middlebox in a service. In addition to the non-IP-to-IP, IPv6-to-IPv4 and cloud gateways described above, some IoT services need applications-layer gateways to interoperate at the command level. Also, people use cloud services to assist them with data aggregation, crowd-sourced information and other useful things in the cloud. This last case is not addressed here but is the subject of “proxy re-encryption.” [2].

An IoT service through connected middleboxes

Figure 3: An IoT service through connected middleboxes

Thus, endpoints need to share certain – but not all – information with gateways, message routers and other middleboxes – according to the principle of least privilege. When TLS, and only TLS, protects a message, however, too much may get shared with gateways, servers, and other intermediate systems. Too much sharing occurs when a middlebox receives a message from one TLS connection, processes the cleartext message and sends it over a second TLS connection. This is hop-by-hop security whereby the middlebox gets to see the contents of each message between a sender and a receiver in an IoT service.

Hop-by-hop security loses more than confidentiality: The source and destination endpoints cannot authenticate each over multiple TLS “hops.” It is a serious weakness when a destination acts upon messages that it cannot validate. There are additional weaknesses with hop-by-hop security including multiple attack targets and fate sharing with a compromised middlebox.

End-to-End and Hop-by-Hop Security

Despite its shortcomings, hop-by-hop security complements end-to-end security: Even if the message payload is in an encrypted envelope, some cleartext metadata may be needed for middlebox processing: Addresses are read to forward the message, for example. Metadata may be shared as needed by other services: Tags for message logging, storage and retrieval might be integrity-protected but not encrypted. A hop-by-hop secure connection such as TLS encrypts these metadata on the network and thereby limits metadata exposure.

Figure 4: An End-to-End IoT Service Envelopes

Figure 4: An End-to-End IoT Service Envelope

Figure 4 illustrates how IoT data and user personal-identifying information are protected end-to-end in an “envelope.” The sender places any metadata needed for network or cloud processing “outside” the envelope, authenticates and encrypts the message with a symmetric key before transmitting key, metadata and message to the intended destination. Public key cryptography (PKC) or a symmetric key are used to authenticate an endpoint, integrity-check a message and encrypt it, end-to-end.   Well established techniques for this date back to the 1990’s in Cryptographic Message Syntax (CMS) and in the email standards such as PGP and S/MIME, which is based on CMS. Thus, envelopes use PKC and symmetric cryptography.

The IoT industry is moving to public-key cryptography in addition to symmetric cryptography: ZigBee, Thread, Z-Wave and Homekit are just some of the standards that support or have announced support for Elliptic Curve PKC on IoT devices. Interoperable standards exist for secure envelopes such as IETF JSON Object Signing and Encryption (JOSE). Its binary representation is CBOR Object Signing and Encryption (COSE), a work-in-progress for the Concise Binary Object Representation (CBOR). These standards update and presumably improve the earlier enveloping technologies such as CMS, but all still lack key-management definition. This is one way that end-to-end IoT security today lags behind Internet chat.

Conclusion: Taking a Clue from Internet Chat

Internet chat is unlike IoT and machine-to-machine applications. Nonetheless, IoT practitioners would do well to follow the example of chat. Protocols like XMPP typically use TLS between chat servers and user devices and to other chat servers. These servers are in the middle of all chat sessions, however, and TLS alone has all of the shortcomings for chat that are described above for hop-by-hop IoT security.

The past decade has seen great progress in end-to-end chat security. User chat data increasingly remain encrypted and authenticated while stored and forwarded through chat servers. Off-The-Record (OTR) protocol, is now widely used in XMPP sessions. In recent years, OTR has been extended by more recent protocols. WhatsApp recently announced that it is using one of these protocols, Signal/Noise [3] to protect up to a billion endpoints, end-to-end through a store-and-forward messaging service.

End-to-end security is vital to the health and growth of IoT. As Bruce Schneier has pointed out, data is a toxic asset – and not just to the many organizations that suffer a serious intrusion every month. An antidote to data toxicity is to keep user data private to the user.   This implies not only encryption but strong authentication of users, devices and cloud services. Envelopes or cryptographic messages can serve to encrypt, integrity protect and authenticate IoT commands, responses, notifications and data through store and forward as well as connection-based communications networks. For this reason, there is considerable interest among IoT bodies that JOSE, COSE or some other emerging technologies will successfully secure IoT services on the network and through application-layer gateways and servers to secure IoT communications comparable to WhatsApp has achieved in its chat service. This is one of the greatest challenges in IoT security.


[1] H. Tschofenig, J. Arkko, D. Thaler, and D. McPherson, “Architectural Considerations in Smart Object Networking,” Informational RFC, IETF, 2015.
[2] P. Hallam-Baker, “Mesh/Recrypt A New Approach to Messaging,” Internet Draft, IETF, 2016.
[3] “WhatsApp’s Signal Protocol integration is now complete,”, 2016