OSCORE: A look at the new IoT security protocol
The 22 billion IoT devices which are forecast to be in operation by 2024 require a critical end-to-end security framework. OSCORE is a new lightweight IoT security protocol which is designed specifically for constrained nodes. What is it and how will it protect tomorrow’s IoT networks? Read below to find out.
As with common Internet nodes such as web servers and mobile phones, connected embedded IoT devices should also support a web-based interaction paradigm with requests and responses using uniform resource identifiers (URIs). However, compared to web servers and mobile phones, IoT devices can be more constrained in performance, availability and power. Therefore, the default techniques used in the Internet today must be replaced with more lightweight dedicated variants suitable for constrained IoT devices.
In July 2019, the Internet Engineering Task Force (IETF) published a new standard (RFC 8613) which is designed to protect web-based interactions in constrained IoT deployments. This new communication security protocol is known as OSCORE (Object Security for Constrained RESTful Environments).
In this post, we recall the design objectives which motivated the development of this IoT security protocol and, as open source code for OSCORE becomes more mature, we look ahead to upcoming milestones for protecting the Internet of Things at the application layer.
CoAP and IoT communication security
One example of a dedicated technology replacing default techniques used in the Internet is the Constrained Application Protocol (CoAP). This provides the REST services of HTTP, however with reduced overhead and processing. CoAP is also designed to support proxy functionality, including the forwarding of messages based on device and network availability allowing sleepy devices and lossy networks.
To secure the communication, a dedicated protocol can be applied to minimize the performance impact and, at the same time, flexibly support different trust models. For example, a gateway on the communication path between a thing and the cloud may perform important functionality to support the communication between the endpoints, but still not be trusted with accessing the application layer payload. The security endpoints for communication with IoT devices, however, should be determined by the business logic instead of the transport protocols and availability of the endpoints.
To achieve this, application layer messages may need to be protected across different transport protocol, even non-IP, through various gateways and over low-power radio such as NB-IoT where the performance impact is most critical. This is one example of a setting where OSCORE is expected to perform well.
CoAP in itself is designed for extremely lightweight operations and can be run on tiny sensor platforms. OSCORE is defined as an extension to CoAP and reuses CoAP's serialization of messages.
OSCORE (RFC 8613) protects the application layer request/response messages between the endpoints: not only the payload containing the value associated to an indicated resource, but also the request method, the identifier of the resource, and the content format of the payload. In this way, the application relevant data and semantics of the request/response can be protected in a way which is decoupled from the transport of the messages, and it is also lightweight in terms of overhead.
In addition to CoAP, OSCORE also uses the Concise Binary Object Representation (CBOR) for compact encoding and the CBOR Object Signature and Encryption (COSE) for encryption and key derivation structures - both designed for constrained device operations - and further compressed with OSCORE by omitting redundant information. OSCORE has built-in identifiers enabling end-to-end operations over multiple different paths with or without IP.
The message overhead is minimal since OSCORE protects only the relevant application layer information and the amount of data added to the size of the original CoAP message can be as low as 11-13 bytes with built-in identifiers. OSCORE has been instrumental in defining the level of overhead for lightweight communication security and outperforms state-of-the-art transport layer security.
Mode of operation
OSCORE operates on a plaintext CoAP message and produces an OSCORE protected CoAP message. The message fields of a CoAP message are classified as protected fields or unprotected fields; protected fields are encrypted and integrity is protected between the endpoints whereas the unprotected fields visible to proxies allow certain support operations. OSCORE may be complemented, for example, with TLS/DTLS terminating at intermediate nodes, allowing hop-by-hop protection of additional header fields.
OSCORE can also provide end-to-end protection between endpoints communication CoAP-mappable HTTP and works with CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP proxies.
OSCORE is specified to offer end-to-end encryption, integrity, replay protection, and binding of response to request.
The latter is important to prevent attacks involving forwarding of a response intended for one request to another request. OSCORE requires a pre-shared master secret to derive a security context with which the communication is protected. The security context may be used for the lifetime of the device provided it is securely updated if the mutable part of the security context is lost, e.g. due to device reboot. As an alternative procedure, the master secret may be used multiple times with an initiation protocol to derive different security contexts between the same or different endpoints. The master secret may have been established out-of-band or with a key establishment protocol (e.g. using the OSCORE profile of the ACE authorization framework). These procedures allow very lightweight key management and exclusively symmetric key operations, which can be complemented with a lightweight authenticated key exchange (LAKE) procedure providing forward secrecy (e.g. using EDHOC).
Additionally, OSCORE is designed to secure group communications, for example using CoAP over multicast IP, protecting multicast requests and optional associated responses.
OSCORE applicability and open source software
OSCORE, like CoAP, was conceived for constrained RESTful environments, i.e. devices and networks of limited performance using the web paradigm for accessing resources. Therefore, OSCORE is especially well suited for IoT frameworks using CoAP, such as OMA Specworks Lightweight M2M (LwM2M) and Open Connectivity Foundation/IoTivity (OCF). Although being designed for the low definition setting, OSCORE can also be applied in non-constrained settings, either by using CoAP also in non-constrained endpoints, or by mapping between HTTP and CoAP.
Many implementations of OSCORE as extensions to several CoAP libraries are in progress at different stages in several different programming languages, and many of them are available as open source, including: Californium (Java), aiocoap (Python), CoAP.NET (C-Sharp) and libcoap (C). Some of these are targeting specific operating systems including Contiki-NG, OpenWSN, RIOT OS and Zephyr OS. Additionally, a more general portable C implementation, libOSCORE, usable for embedded devices is in progress. Open source OSCORE code for LwM2M is also in progress in its CoAP library Leshan (Java), as are testing tools for OSCORE in the F-interop testing platform and in the Wireshark dissector.
Next steps in standardization
In collaboration with RISE, we have driven and finalized the standardization of the communication security protocol OSCORE in IETF, by publishing RFC 8613.
Today, a supporting range of standard specifications which aim to cover related scenarios and protect IoT with lightweight security protocols are in progress. This includes standardization work on securing group communication using CoAP (Group OSCORE), on authorization and access control in constrained environments (ACE), as well as on standardizing a lightweight authenticated key exchange (LAKE), to provide forward secrecy for OSCORE keying material.
Visit our IoT security page to learn more about the factors which impact IoT security.