hoglund22secure
- Sara Faour
Title of the paper: Secure Communication for the IoT: EDHOC and (Group) OSCORE Protocols
Available at: Not published yet
Abstract
The article overviews the standardization activity within the Internet Engineering Task Force (IETF) and describes the state-of-the-art lightweight security protocols for Internet-of-Things use cases.
Introduction
For reducing power consumption in wireless networking, the following are designed:
IoT radio standards such as LoRaWAN and 6TiSCH
Cellular technologies, such as NB-IoT
The Internet Engineering Task Force (IETF) has been working on defining lightweight protocols for the IoT. Prominent examples include:
the Constrained Application Protocol (CoAP), a web transfer protocol similar to HTTP,
6LoWPAN, a compression layer for IPv6,
and 6TiSCH, an efficient protocol stack that runs over IEEE 802.15.4 radios.
The overall communication security of an IoT networking stack relies on different protocols used throughout the product lifetime. This includes:
onboarding (the procedure by which an IoT device is provisioned with deployment specific parameters),
the join process of an authorized network,
key exchange with different application entities,
communication security and
data protection.
Building Blocks
There are four main building blocks which are developed for constrained low-power wireless systems: CoAP, CBOR, COSE and C509. Both one-to-one and secure group communication, detailed later, build on top of these.
CoAP: Constrained Application Protocol
CoAP standard (RFC7252) defines a web transfer protocol, similar to HTTP, adapted for constrained networking technologies, and specialized for IoT communication paradigms such as group communication and asynchronicity.
One of CoAP’s core features is caching at intermediaries; this allows a consumer to retrieve an IoT device’s data even when that device has its radio off.
CBOR: Concise Binary Object Representation
CBOR standard (RFC8949) is a data format designed for encoding compactness, small code size and extensibility.
CBOR defines several “major types” such as unsigned and negative integers, arrays, and dictionaries.
CBOR is a basic building block of many IoT protocols standardized in the IETF, including the security protocols discussed in this article.
COSE: CBOR Object Signing and Encryption
COSE standard (RFC9052, RFC9053) describes how to create and process representations for cryptographic keys, signatures, message authentication codes, key exchange, and encryption, using CBOR for serialization.
COSE is designed in a way that allows constrained devices to verify protected messages efficiently.
C509 Certificates
CBOR-encoded X.509 (C509) Certificates is an ongoing IETF work item to standardize a CBOR encoding of X.509 certificates suitable in particular for the IoT.
The CBOR encoding already supports a large subset of X.509 certificates.
The C509 encoding can, in many cases, reduce the size of certificates by over 50%, and can be used independently of certificate compression, which when combined may provide additional reduction.
Secure One-to-One Communication
Use Cases
From a networking point of view, the devices in the industrial use case detailed in the paper form a 6TiSCH low-power wireless network.
They use CoAP at the application layer for end-to-end communication between a wireless device and the control software, via caching and forwarding proxies.
The CoAP payload is encoded with CBOR, which may be protected using COSE once appropriate security context is established.
At manufacturing, each device is provisioned with a C509 manufacture certificate, to be used to establish the keying material for the factory deployment.
The following sections describe the different protocols involved for all devices to be securely integrated in the factory network, and to be able to establish and maintain secure and protected interactions among themselves. All protocols build on the building blocks discussed above.
EDHOC: Establish Keying Material
The Ephemeral Diffie-Hellman Over COSE (EDHOC) is the protocol which establishes a shared symmetric key between two devices, using the certificates they have pre-loaded, or other types of authentication credentials.
EDHOC is based on an authenticated Diffie-Hellman key exchange. It is designed to be lightweight with
low overhead, suitable for resource-constrained environments.
EDHOC achieves a small message size which compares favorably to alternatives such as (D)TLS.
The overall security design of the protocol is based on the SIGMA-I MAC-then-SIGN variant which provides forward secrecy, the guarantee that a compromise of long-term authentication credentials or of a session key does not compromise past session keys; protection of identities; and mutual authentication of the peers.
EDHOC uses COSE for cryptographic operations, CBOR for data encoding, and is typically transported over CoAP.
OSCORE
Object Security for Constrained RESTful Environments (OSCORE) is the protocol which allows protection of CoAP messages at the application layer, while enabling those to be forwarded by the proxy.
OSCORE ensures confidentiality, replay protection, message authentication, message integrity and message ordering. It provides end-to-end security from message producer to message consumer, potentially via intermediaries such as proxies.
It is particularly suited for resource constrained environments and its design puts emphasis on small size of messages and small code footprint in order to ensure operation in constrained networks.
It relies on CBOR for data encoding, and COSE for the security-related services such as encryption needed by the protocol. In addition to CoAP, the OSCORE protocol can also be transported over HTTP and supports proxy operations for translating between CoAP and HTTP.
The security of OSCORE is based on authenticated symmetric encryption. By utilizing EDHOC, peers can start from asymmetric key material to establish a shared secret for keying OSCORE.
OSCORE takes a CoAP message as input and produces a protected CoAP message as output.
Optimizing EDHOC+OSCORE
When using EDHOC and OSCORE together, their operation can be optimized:
Renew Keying Material
There are several reasons why renewing keying material is important.
One reason may be the exhaustion of sequence numbers used for the construction of nonces.
Another reason may be the exhaustion of usage limits for the keying material.
There are several ways of rekeying.
It is possible to use EDHOC’s KeyUpdate function without the additional communication overhead. KeyUpdate guarantees that a compromised long-term authentication key does not compromise past session keys (forward secrecy), and that the compromise of an (EDHOC) session key does not compromise past session keys. With KeyUpdate, however, the compromise of a single session key compromises all future session keys, as the new session key is derived based on the old session key.
It is also possible to rerun the full EDHOC handshake and generate a new shared secret and OSCORE Security Context. Rerunning the full EDHOC handshake guarantees that the new keys satisfy the strongest security properties, as provided by EDHOC.
Finally, an ongoing work specifies the KUDOS protocol, another way to rekey OSCORE at the application layer.
Secure Group Communication
Even though this could be achieved by having one-to-one communication with each device of the group, this adds significant overhead in terms of network bandwidth and discovery.
From a networking point of view, protocols such as 6TiSCH and 6LoWPAN (IPv6) have broadcast and multicast capabilities built in. This means that a message sent by the central controller can efficiently reach a group of devices. But how can such group communication be done securely?
Group OSCORE protects end-to-end CoAP requests addressed to one or multiple recipients in a group, as well as the corresponding unicast CoAP responses. As in OSCORE, the responses are cryptographically bound to the same associated request.
Group OSCORE fulfills similar security requirements as OSCORE and provides confidentiality, replay protection, source message authentication, message integrity and message ordering.
All members of an OSCORE group share the same symmetric keying material used for encryption. They are, therefore, able to decrypt messages exchanged in the group. Source message authentication is achieved through digital signatures when using the group mode.
Group OSCORE relies on a trusted third party, the Group Manager, as the responsible for managing OSCORE groups.
Multicast Notifications
The Observe feature of CoAP allows a client to register its interest at a server resource. Upon changes in the resource representation, the client automatically receives notification responses from the server, which are all bound to the original request.
Cacheable Protected Responses
The native CoAP support for intermediaries such as proxies is especially convenient for message forwarding and response caching. A proxy can forward requests to the origin server (where the desired resource resides) on behalf of the client, and relay back the corresponding responses.
The proxy can also cache responses from the origin server and use them to serve followup requests to the same resource. This avoids accessing the origin server again, which is particularly useful if the server is a constrained IoT device accessed over low-power radio technology.
One proposed work in the IETF enables the proxy to effectively cache responses that are OSCORE protected, i.e., end-to-end secure. The method builds upon Group OSCORE and requires the origin server and clients to be the members of the same OSCORE group.