Object Security for Constrained RESTful Environments

Description

Object Security for Constrained RESTful Environments (OSCORE) is an application-layer security protocol standardized by the IETF and adopted by 3GPP for securing IoT communications, particularly those using the Constrained Application Protocol (CoAP). Unlike transport-layer security (TLS/DTLS), which secures an entire channel, OSCORE applies protection directly to the CoAP message, transforming it into a secure 'OSCORE message' that encapsulates the original CoAP options and payload. This process is known as 'object security' because the security is bound to the message object itself. The core of OSCORE's operation is the use of the COSE (CBOR Object Signing and Encryption) format for cryptographic operations, specifically employing the AES-CCM algorithm for providing confidentiality, integrity, and authentication of the protected message fields.

OSCORE works by establishing a shared security context between two endpoints (e.g., an IoT device and an application server). This context includes a Master Secret, a Sender ID, and a Recipient ID. From the Master Secret, deriving keys and an Initialization Vector (IV) for each message are generated. Each message is assigned a unique Sequence Number (Sender Sequence Number) by the sender, which is used in the IV derivation to prevent replay attacks. The sender encrypts and integrity-protects the CoAP payload and certain sensitive CoAP options (like Uri-Path), while leaving other options (like those needed for proxy routing) unprotected. The resulting OSCORE message includes the Sender ID, a partial IV (derived from the Sequence Number), and the ciphertext. The recipient uses its security context, the received Sender ID, and the partial IV to reconstruct the full IV, decrypt the payload, and verify integrity.

In a 3GPP network, OSCORE's role is crucial for securing end-to-end communication in IoT scenarios, especially within the Service Capability Exposure Function (SCEF) or Network Exposure Function (NEF) interfaces for Non-IP Data Delivery (NIDD) and other constrained device services. Its key architectural advantage is that it allows messages to remain secure while traversing intermediaries like CoAP proxies or network gateways, which may need to read or modify unprotected CoAP options (e.g., for caching or routing) but cannot access the protected application data. This makes it ideal for low-power, lossy networks (LLNs) where transport-layer security sessions can be expensive to maintain and where hop-by-hop security is insufficient for ensuring data confidentiality all the way to the application server.

Purpose & Motivation

OSCORE was created to solve the specific security challenges inherent in the Internet of Things (IoT), where devices are often severely constrained in terms of processing power, memory, and energy. Traditional security protocols like TLS/DTLS, while robust, can be too heavy for such devices, requiring significant resources for session establishment, maintenance, and per-packet overhead. Furthermore, in IoT deployments, communications frequently pass through intermediaries (proxies, gateways) for protocol translation or network optimization. TLS provides only hop-by-hop security, meaning the intermediary becomes a trusted entity that can see plaintext data, which is undesirable for end-to-end security and privacy.

The primary problem OSCORE addresses is how to provide efficient, end-to-end security for the payload and critical metadata of CoAP messages without imposing the overhead of maintaining a stateful transport-layer security tunnel. It was motivated by the need for a security solution that works in constrained environments, supports the RESTful paradigm of CoAP, and allows for the legitimate operation of intermediaries without breaking security. By securing the 'object' (the CoAP message) itself, OSCORE decouples security from the underlying transport, enabling secure communication over unreliable transports and through untrusted nodes.

3GPP adopted OSCORE to enhance the security of IoT services in its architecture, particularly for services exposed via the NEF/SCEF. It addresses limitations of previous approaches where IoT device data might only be protected between the device and the mobile network, but not all the way to the application server in the cloud. By mandating OSCORE for certain interfaces, 3GPP ensures that sensitive IoT data, such as sensor readings or control commands, remains confidential and integral from the constrained device to its final destination, even when traversing the 3GPP network infrastructure and external IP networks.