Source-linked AI summary
OSCAR: Object Security Architecture for the Internet of Things
Malisa Vucinic, Bernard Tourancheau, Franck Rousseau, Andrzej Duda, Laurent Damon, Roberto Guizzetti
TL;DR
Constrained IoT systems need security that supports asynchronous traffic, caching, multicast, and many clients without the scalability costs of connection-oriented state. OSCAR combines object security with (D)TLS-based key distribution and CoAP coupling, and the paper evaluates its feasibility while reporting energy benefits at constrained servers. Its stated scope excludes use cases requiring streaming.
Problem
Existing connection-oriented IoT security does not adequately support asynchronous traffic, caching, multicast, and large numbers of clients on constrained devices.
Method
OSCAR uses object security for content protection, capability-based access control, and replay protection while using secure (D)TLS channels for key distribution.
Results
The paper demonstrates OSCAR’s feasibility in constrained M2M communication and reports reduced ECDSA computation time by a factor of 4 on a 32-bit MCU.
Takeaways & Limitations
OSCAR is presented as a scalable solution for energy-constrained servers with many clients, particularly in Smart City deployments.
Takeaways & Limitations
Use cases requiring streaming remain part of ongoing work and are not covered by the paper.
Abstract
from arXiv · showhide
Billions of smart, but constrained objects wirelessly connected to the global network require novel paradigms in network design. New protocol standards, tailored to constrained devices, have been designed taking into account requirements such as asynchronous application traffic, need for caching, and group communication. The existing connection oriented security architecture is not able to keep up---first, in terms of the supported features, but also in terms of the scale and resulting latency on small constrained devices. In this paper, we propose an architecture that leverages the security concepts both from content-centric and traditional connection-oriented approaches. We rely on secure channels established by means of (D)TLS for key exchange, but we get rid of the notion of the 'state' among communicating entities. We provide a mechanism to protect from replay attacks by coupling our scheme with the CoAP application protocol. Our object-based security architecture (OSCAR) intrinsically supports caching and multicast, and does not affect the radio duty-cycling operation of constrained objects. We evaluate OSCAR in two cases: 802.15.4 Low Power and Lossy Networks (LLN) and Machine-to-Machine (M2M) communication for two different hardware platforms and MAC layers on a real testbed and using the Cooja emulator. We show significant energy savings at constrained servers and reasonable delays. We also discuss the applicability of OSCAR to Smart City deployments.
I. INTRODUCTION
IoT security mechanisms designed around connection-oriented trust do not fit constrained devices that depend on asynchronous traffic, caching, and group communication. OSCAR addresses this mismatch by combining object security with authenticated (D)TLS channels for key distribution while removing persistent client-server security state.
- Motivation: Constrained IoT devices rely on asynchronous traffic, caching, and group communication, but existing connection-oriented security does not adequately support these requirements.These requirements are difficult to support simultaneously with existing security mechanisms designed for point-to-point communication.
- Motivation: DTLS is incompatible with multicast and caching, while constrained servers cannot maintain security sessions for many clients without increased load and energy consumption.Memory limits restrict the number of handled sessions, creating scalability problems in deployments with many clients per server.
- Approach: OSCAR removes security state between servers and clients by protecting information content itself and coupling object security with capability-based access control.The architecture provides confidentiality and replay protection while retaining secure channels for authenticated key exchange.
- Contributions: OSCAR jointly provides end-to-end security and access control while supporting multicast, asynchronous traffic, and caching.The architecture separates confidentiality and authenticity trust domains.
- Contributions: The paper evaluates OSCAR in constrained M2M scenarios across two hardware platforms and MAC layers using a real testbed and the Cooja emulator.The evaluation is designed to examine performance as the number of clients increases.
III. OSCAR
OSCAR uses object security to meet IoT requirements while minimizing security-related radio communication. Its design accepts more computation in order to reduce extra transmitted and received frames, under assumptions of persistent energy and memory constraints but increasing processing capability.
- III. OSCAR: OSCAR uses object security to provide greater flexibility while addressing the requirements of constrained IoT systems.The design is motivated by the expectation that energy and memory remain limiting constraints.
- Design assumptions: Energy remains the main constraint for IoT devices, while embedded memory is expected to remain limited and economically important.The paper treats these constraints as persistent design conditions.
- Design goal: Processing capability is expected to increase, so OSCAR prioritizes minimizing extra security frames and packets over minimizing computation.The architecture trades radio usage for a higher computation load.
B. Producer-Consumer Model
OSCAR organizes security around producers and consumers: producers secure resource representations, while consumers with access privileges retrieve and validate them. This minimizes producer-side handshakes and shifts authentication and access-secret management toward more capable trusted parties.
- Producer-Consumer Model: The producer-consumer model treats IoT devices as producers of secured resource representations and consumers that use authorized content.The model reflects information flows among sensors, actuators, collection centers, and human users.
- Producer responsibilities: Producers avoid consumer-specific security handshakes, because access-protected resource representations are cheaper than multiple round-trip handshakes.IoT resource representations are typically small measurements or device states.
- Access control: OSCAR offloads authentication from constrained servers to semi-trusted third parties that authenticate consumers and distribute access secrets and certificates.Consumers can fetch protected content from intermediate proxies or directly from producers.
- Trust domains: Confidentiality provides capability-based access control and protection against eavesdropping, while authenticity and integrity remain tied to the host and signed content.These services are treated as separate trust domains.
- Object security: Producers locally retain cached, signed resource representations that can serve different consumers without a logical producer-consumer association.This model supports direct request-response interactions as well as asynchronous updates.
C. Fitting the Concept with the REST Architecture and CoAP
OSCAR couples object security with CoAP by representing access secrets as REST resources and protecting content at the application layer. This enables stateless protection while allowing authorization policies to determine secret-resource relationships.
- CoAP integration: Object security is coupled with CoAP to protect secured objects against network adversaries without maintaining communication state.The coupling binds application-layer secured objects to the underlying RESTful protocol.
- Access-secret management: Access secrets are modeled as REST resources that can be created or updated with PUT only when signed by a trusted authority.The server validates the enclosed new access secret before allowing the change.
- Access control: The relation between each access secret and resource depends on authorization policies and the required confidentiality level.The relationship is part of the resource and supports different confidentiality and access-right groups.
- Processing model: In OSCAR’s CoAP coupling, server-side digital signing is performed offline, while symmetric encryption is performed online using a key derived from K.The encryption key for a new access secret may depend on the key-management scheme.
1) Replay protection:
OSCAR derives content-encryption keys from CoAP’s MessageID and sender identity, enabling replay detection without maintaining endpoint state. The approach remains vulnerable when delayed content outlives the MessageID context.
- Replay protection: CoAP’s 16-bit MessageID supplies the salt for deriving each response’s content-encryption key.The sender identity is also incorporated to prevent identical keys across different senders in a group.
- Replay protection: Fig. 3 binds the object-encryption key to the underlying CoAP header, with the signed object nested as encrypted payload.
- Replay protection: The key is derived from the access secret, current MessageID, and sender’s unique identifier using a pseudo-random function.Replayed content produces a different decryption key and is detected.
- Replay protection: OSCAR is vulnerable to substantially delayed replays after a client or server loses the communicating parties’ MessageID context.The architecture relies on access-secret updates from the key-management scheme to address this case.
2) Cipher negotiation:
OSCAR uses content-level security and access control rather than relying solely on connection security, while retaining authenticated key exchange through (D)TLS-derived mechanisms. This design supports asynchronous, cached, and group-oriented IoT communication, but its confidentiality properties depend on access-group key management.
- Cipher negotiation: OSCAR preserves content authenticity and integrity with digital signatures while using symmetric encryption per response for confidentiality and replay protection.Public-key verification is shifted to clients, while constrained servers can update signed representations with the radio off.
- Cipher negotiation: ECC public-key operations are reported as less expensive than a pre-shared-key DTLS handshake with every client, including constrained M2M scenarios.
- Cipher negotiation: OSCAR’s stateless design directly responds to small resource representations and avoids retaining state between communicating entities.This is intended to help resist memory-exhaustion attacks.
- Cipher negotiation: Content encryption keys derived from access secrets provide confidentiality within the resource-access-right group.Compromised Authorization Servers may obtain eavesdropping capabilities, while end-to-end integrity and authenticity remain preserved.
- Cipher negotiation: If group members should not share confidentiality, OSCAR places the additional burden on key management at Authorization Servers.
- Cipher negotiation: Asynchronous group members can inject old resource representations unless the content itself enables freshness detection, such as through a timestamp.Different cryptographic material for servers and clients is proposed as a protection mechanism.
V. PERFORMANCE EVALUATION
The evaluation implements OSCAR as a constrained-device object-security library and measures cryptographic overhead across two hardware generations. It combines real hardware experiments with Cooja/MSPSim emulation and reports calibrated energy measurements.
- Implementation: The object-security library supports creation, parsing, and verification of encrypted and signed objects on Contiki-based constrained devices.It uses TinyECC/ContikiECC, AES-CCM*, certificates as signed objects, and nested objects.
- Implementation: Nested signed objects can let a gateway add global timestamps or location information unavailable locally on constrained devices.
- Evaluation scope: The evaluation measures ECDSA computation overhead and M2M scalability across two hardware platforms.
- Evaluation platforms: WiSMote experiments use the MSPSim instruction-level emulator and Cooja because insufficient real platforms were available.Emulated ECDSA overhead was compared with real WiSMote measurements, with a maximum error of 2.67%.
- Evaluation platforms: ST GreenNet experiments use real energy-harvested hardware with a 32-bit ARM Cortex-M3 and 802.15.4 radio.
- Measurement conditions: Both platforms were configured at 21.3 MHz to remove variable CPU frequency effects from the results.Computation time and CPU energy vary linearly with frequency under this setup.
- Measurement conditions: Energest estimates energy by measuring component state durations and multiplying them by 2.8 V and datasheet current draws.
A. ECDSA Computation Overhead
OSCAR’s ECDSA overhead is evaluated across constrained hardware and against DTLS-based alternatives, with the analysis emphasizing computation, energy, scalability, and latency trade-offs.
- ECDSA computation and energy: A 32-bit MCU reduces ECDSA computation time by a factor of 4 and consumed energy by a factor of 3.084 versus the 16-bit platform.The comparison uses secp160r1 and secp192r1 primitives on WiSMote and ST GreenNet at 21.3 MHz.
- ECDSA computation and energy: ECDSA computation overhead ranges from 0.3 to 0.9 seconds on the 32-bit platform and from 1.18 to 3.63 seconds on the 16-bit platform.OSCAR offsets this computation cost by removing radio energy for a security handshake with every client.
- Server scalability: At β = 60s, OSCAR crosses compressed DTLS energy performance at a client/session slot ratio of approximately 1.3 on WiSMote and 2.15 on ST GreenNet.The crossings depend on the MCU and radio characteristics of the evaluated platforms.
- Client energy: For client/session slot ratios of 3.7 on WiSMote and 4.17 on ST GreenNet, constant ECDSA verification outperforms compressed DTLS in client energy consumption.The evaluation uses constrained clients, representing a worst-case client configuration.
- Latency: Request-response latency is strongly affected by MCU computation, while DTLS latency increases exponentially with client count under the evaluated retransmission configuration.The ST GreenNet deployment also observed more failed DTLS handshakes at 16 clients.
VI. SECURING THE INTERNET OF THINGS
Secure-IoT research and standardization largely place security features within one or more layers of the TCP/IP protocol stack, motivating a survey of existing approaches.
- Secure-IoT research and standardization efforts commonly follow the TCP/IP architectural model.
- Under this model, security features are placed on one or more protocol-stack layers.
- The section surveys the state of the art in layer-based secure-IoT approaches.
A. End-to-End Security at the Network Layer
Network-layer security approaches such as IPsec provide end-to-end protection but fit IoT applications poorly because deployment and protocol-mapping requirements constrain their use.
- Network-layer blanket coverage has been considered a way to provide end-to-end security services for wireless sensor networks.
- Prior work found lightweight IPsec feasible for constrained environments after evaluating processing, energy, memory, and response-time costs.
- IPsec is impractical for typical IoT applications because users would need to configure the host operating system and IPsec for smart-object communication.
- Network-layer integrity prevents HTTP/CoAP payload mapping at gateways, although CoAP was designed to facilitate such mappings for legacy Internet hosts.
B. End-to-End Security at the Transport Layer
Transport-layer security approaches for IoT inherit connection-oriented assumptions that conflict with constrained networks, especially for multicast, caching, and application-layer interoperability. DTLS improves applicability over unreliable transport but retains important overhead and architectural limitations.
- TLS was adapted to DTLS for UDP-based application protocols because unreliable transport and out-of-order delivery make TLS unsuitable for IoT.
- DTLS research for IoT has focused on reducing handshake and datagram overhead, including certificate prevalidation, gateway delegation, and 6LoWPAN compression.
- DTLS is incompatible with multicast because it targets connection-oriented client-server architectures, whereas group communication is a core CoAP requirement.
- Point-to-point DTLS also creates problems for gateways mapping CoAP to HTTP/TLS, because transport-layer integrity verification prevents application-layer CoAP/HTTP mapping.
- Object security has been proposed for application-payload protection, while related work primarily used it for fine-grained access control through assertion-based authorization.
D. Standardization Efforts
Standardization efforts address constrained-device security through DTLS profiling, authorization frameworks, link-layer bootstrapping, and object-security formats. OSCAR combines end-to-end security and authorization while preserving DTLS compatibility, but streaming use cases remain outside the paper’s scope.
- DTLS standardization efforts are revisiting point-to-point assumptions by adding multicast support through the record layer and independent group-key management.
- OSCAR bridges DTLS and ACE requirements by jointly addressing end-to-end security and authorization while remaining compatible with plain DTLS.
- 6TiSCH focuses on bootstrapping IEEE 802.15.4 nodes, including initial network access and Layer 2 key setup using existing IP protocols.
- Existing object-security formats such as CMS and JOSE require adaptation for constrained devices.
- OSCAR places security in application payloads, separates confidentiality and authenticity trust domains, and couples content encryption with CoAP duplicate detection for replay protection.
- The proposal was evaluated in resource-constrained M2M communication and is positioned for Smart City deployments with energy-constrained servers serving many clients.
- Use cases requiring streaming remain part of ongoing work and are not covered by the paper.