OMA-WP-e2e_Sec_IoT-20191024-A Page 4 (22)
2019 Open Mobile Alliance.
Used with the permission of the Open Mobile Alliance under the terms as stated in this document. [OMA-Template-WhitePaper-20191012-I]
2. End-to-End Security for IoT
Some Section 3 use cases need secure messaging at multiple, overlapping communications layers. Link layer security, such
as Wi-Fi WPA2, ensures that only authorized parties can use a particular network. A wireless network is usually one of
multiple networks between IoT endpoints. Transport-layer Security (TLS)
works across those networks and provides
end-to-end security in many use cases, but each middlebox may become an endpoint that may terminate a TLS connection. In
this way, middleboxes destroy transport-layer end-to-end authentication, integrity and confidentiality by creating more than
one transport connection end-to-end. In this case, an IoT service needs more than TLS to achieve end-to-end security:
Security at the application layer preserves end-to-end security over middleboxes and IoT gateways.
Security is applied to the application layer to make it unchangeable and unreadable between application endpoints. When
middleboxes gain unrestricted access to the entire message without needing all the data in the message, this violates the
principle of least privilege. Application-layer forwarding does not need disclosure of application layer data contents at all.
IoT services often include constrained devices, which are constrained in power, computation and networking capabilities
[RFC7228]. For example, security at three layers may be too demanding of these resources. What layers can be skipped
depends on the needs of the particular application and environment. The following subsections consider what applications
need to protect, where they need to protect it, and when.
2.1 What Needs to be Protected?
Different types of IoT assets need to be protected. IoT devices and user interfaces are IoT-endpoint assets such as light
bulbs, mobile phones, doorbells, locks, commercial and industrial sensors and actuators. IoT gateways, brokers, proxies, and
firewalls are middlebox assets. Endpoints and middleboxes create, consume or process information assets, such as
application-layer payload, metadata, and addressing information. This paper focuses solely on information assets and
assumes proper operational security in endpoint and middlebox assets.
Endpoints that depend on the security of middleboxes share fate with them: Middleboxes are common targets of mass-
surveillance [Constantin], extortion [Mirai], and other attacks. Thus, each middlebox hop of decryption, processing, and re-
encryption incrementally increases IoT security risks. There's more risk when middleboxes can read more message data than
they need or endpoints collect more data than they need. Privacy-by-design minimizes collected data according to a
documented need. Data are risky and even toxic [Schneier] to organizations. This paper assumes secure data design, but data
design is outside the paper's scope, which is protecting IoT messages that contain the data regardless of data architecture.
In this paper, protection is application-layer message authentication and confidentiality. It also includes protection against
message replays. Data about the message also need some protection: Metadata such as instruction/error code, content format
or other application related information expressed in the application-layer header fields typically need at least integrity
protection. Source and destination network addresses, host addresses, and port numbers typically exist outside of the scope
of the application and are often used by middleboxes along the service path such that they should neither be encrypted nor
integrity protected: Message routers, for example, filter on address and other fields; forwarding proxies may change
destination addresses.
Some metadata, moreover, reveal personal information or other confidential data that only intended endpoints should read.
Other metadata are mutable and don't figure into endpoint authentication of the message. Hence, not all metadata must be
protected end-to-end, but LwM2M application security and comparable protocols must properly protect metadata that do.
Write operations to devices, such as device configuration or actuation, may require additional security considerations. For
example, a physical lock does not only need to be protected against replay, it must also be able to verify that an unlock
request is fresh to avoid delayed unlock requests from being accepted. Furthermore, to verify the current state of a device
requires a binding of response to request, so that delayed responses are not accepted.
2.2 When and Where Does It Need to be Protected?
Some IoT applications resemble email and chat services: Like a PC, an IoT device may be intermittently offline to save
power, or due to a low-powered or lossy network. In many cases, transport-layer security doesn't protect store-and-forward
message delivery end to end, just hop-by-hop. Many IoT messages are delivered over a connection with data sent and
Refer to [TLS] and [DTLS] for details on transport-layer security.