Object Security for Constrained RESTful Environments (OSCORE)

Object Security for Constrained RESTful Environments (OSCORE)
Name	Object Security for Constrained RESTful Environments
Abbreviation	OSCORE
Status	Standardized
Year	2018
Organization	IETF
Related	CoAP, DTLS, CBOR, COSE

Object Security for Constrained RESTful Environments (OSCORE) OSCORE is an IETF standardized mechanism for end-to-end security in constrained environments, designed to protect Constrained Application Protocol messages between endpoints in networks typified by limited resources and intermittent connectivity. It complements transport-layer protections such as Datagram Transport Layer Security while integrating with application-layer models influenced by Representational State Transfer, Constrained Application Protocol, and compact encoding schemes like Concise Binary Object Representation.

Overview

OSCORE was developed within the Internet Engineering Task Force working groups drawing on concepts from IETF ACE Working Group, IETF CoRE Working Group, and security protocols discussed at venues such as IETF 101 and IETF 102. The specification interoperates with authentication frameworks including OAuth 2.0 and key management approaches like ACE Framework profiles. It targets deployments in ecosystems championed by organizations such as the Open Connectivity Foundation, Zigbee Alliance, and industry consortia including LoRa Alliance, where devices from manufacturers like ARM Holdings, Texas Instruments, and STMicroelectronics implement constrained stacks.

Design and Architecture

OSCORE's architecture separates object-level protection from transport and network layers, aligning with architectural principles advocated by Roy Fielding and the Representational State Transfer (REST) style. It maps application-layer messages encoded with CBOR into protected COSE objects as specified by COSE and coordinates with routing technologies such as 6LoWPAN, RPL, and link-layer technologies including IEEE 802.15.4 and Bluetooth Low Energy. The design was influenced by research from institutions like ETH Zurich, University of Cambridge, and INRIA showing benefits of end-to-end protection across intermediaries such as Constrained Application Protocol (CoAP) proxies.

Cryptographic Mechanisms

OSCORE uses the CBOR Object Signing and Encryption (COSE) framework for format and cryptographic bindings, employing algorithms from standards bodies like IETF CFRG and references to suites such as AES-GCM, ChaCha20-Poly1305, and key derivation functions defined by HKDF. Key establishment methods compatible with OSCORE include pre-shared keys, asymmetric mechanisms using Elliptic Curve Cryptography curves promoted by SECG and NIST, and automated provisioning via protocols discussed at IETF ACE. Cryptographic parameters can be negotiated or provisioned with guidance from organizations like IANA for algorithm identifiers and registries maintained by the IETF Security Directorate.

Protocol Operation and Message Flow

In operation, a client and server exchange COSE-protected payloads, where OSCORE transforms CoAP messages into protected objects while preserving semantic elements such as method, URI, and options required by intermediaries like CoAP proxies and gateways deployed by vendors like Cisco Systems and Ericsson. Message flow scenarios documented in the specification mirror architectures used by testbeds at RIOT OS, Contiki-NG, and Zephyr Project communities. Replay protection, sequence numbers, and context establishment follow patterns similar to mechanisms in IPsec and DTLS but operate end-to-end at the application object level, enabling secure caching by intermediaries akin to content delivery facilitated by entities such as Akamai.

Interoperability and Profiles

OSCORE profiles have been defined to work with ecosystem profiles from organizations such as the Open Connectivity Foundation, OneM2M, and standardization efforts at IEEE. Interoperability testing has been conducted at events like IETF Hackathons and collaborative testbeds organized by Eclipse Foundation projects and academic partners including TU Delft and KAUST. Profiles specify algorithm sets, key management bindings to frameworks like ACE, and integration points with management protocols used by Network Working Group implementations.

Security Considerations

Security analyses by researchers from University of Oxford, MIT, and TU Darmstadt have evaluated OSCORE's resistance to threats cataloged in frameworks such as STRIDE and adversary models discussed in IETF RFC 3552. Threats addressed include eavesdropping, message forgery, replay attacks, and context compromise; residual risks relate to key management, physical compromise of constrained hardware from vendors like NXP Semiconductors, and metadata leakage through traffic analysis studied by groups at Carnegie Mellon University. Mitigations reference operational practices promoted by IETF Operations and Management and recommendations from agencies such as ENISA.

Implementations and Deployments

Multiple open-source and commercial implementations exist in projects such as libcoap, Copper (CoAP) plugin, Eclipse Californium, AIoT Stack and stacks from vendors like ARM mbed, Silicon Labs, and Nordic Semiconductor. Deployments have appeared in smart city pilots supported by municipalities like Barcelona and Amsterdam, industrial IoT trials with companies including Siemens and Schneider Electric, and research testbeds at Imperial College London and Fraunhofer Society. Ongoing work in standards bodies and consortia continues to shape adoption, certification, and interoperability efforts across the Internet of Things landscape.

Category: Internet standards