Stateless Approach to End-to-End Security for the Internet of Things (OSCAR Object Security Architecture for the IoT)

(1)

January 2014 GreenNet Presentation

Stateless Approach to End-to-End Security

for the Internet of Things

(OSCAR – Object Security Architecture for the IoT)

Mališa Vučinić v★, Bernard Tourancheau v, Franck Rousseau v, Andrzej Duda v, Laurent Damon ★, and Roberto Guizzetti ★.

v Grenoble Informatics Laboratory, France

★ STMicroelectronics

(2)

Security in the traditional Internet (1/2)

2

Alice

(D)TLS client (D)TLS server

Bob

Authenticated Secure Channel established once handshake completes

Bidirectional Information Flow

Bob

RSA and AES Key: 0x9c6d3

Alice

(3)

Security in the traditional Internet (2/2)

3

Bob

Alice

Alice

Carol

Wendy

Erin

Erin

ECC and AES Key: 0xdf71e

Carol

ECC and AES Key: 0x1e8c2

Wendy

RSA and AES Key: 0x1f61a

(4)

Security in the Internet of Things

4

Bob

Alice

Carol

Wendy

Erin

z

Proxy Server

(5)

Security in the Internet of Things

5

Bob

Alice

Carol

Wendy

Erin

z

What happens to the End-to-End Security ?

Proxy Server

(6)

Motivation

6

• Features of the Constrained Application Protocol (CoAP) when

secured by DTLS:

•  Group communication i.e. multicast support

•  Asynchronous message exchanges

•  Proxy and caching capabilities

•  Low overhead •  Header mapping to HTTP

✕

±

✕

(7)

MAC IPv6 UDP CoAP F CS Signed Object Encrypted Object

OSCAR – concepts behind (1/2)

Object Security Architecture for the Internet of Things [1]

7

• Idea 1:

A stateless security architecture

•  Allows caching, eases group communication and asynchronous exchanges

•  Solution: Object security – Application data encapsulated within “secured objects”

•  Protect from communication-related attacks by binding object-security encryption

keys with the underlying CoAP header

[1] M. Vučinić, B. Tourancheau, F. Rousseau, A. Duda, L. Damon, R. Guizzetti,

OSCAR: Object Security Architecture for the Internet of Things, in: WoWMoM, IEEE, 2014, pp. 1–10. Object Type: Signed

Origin: Temperature sensor in room D326

Key ID: 0xf61c

Signature: 0xc2779b20ea27a Temperature reading: 25.5 °C

Timestamp: 10:42 AM

Object Type: Encrypted Key ID: 0xfa1c

(8)

8

• Idea 2:

Move the burden of security handshake away from sensors

•  Introduce a semi-trusted, non-constrained third party that will do the hard work

•  Sensors respond with secured objects (resource representations) regardless of the

identity of the client

OSCAR – concepts behind (2/2)

Object Security Architecture for the Internet of Things [1]

(9)

9

• Idea 2:

Move the burden of security handshake away from sensors

•  Introduce a semi-trusted, non-constrained third party that will do the hard work

•  Sensors respond with secured objects (resource representations) regardless of the

identity of the client

• Idea 3:

Jointly approach problems of End-to-End security and

Authorization

•  Split confidentiality and authenticity trust domains

•  Confidentiality used to provide access-control for group members

•  Authenticity strongly tied to the originator of the information (individual sensor)

OSCAR – concepts behind (2/2)

Object Security Architecture for the Internet of Things [1]

(10)

(11)

OSCAR – dive deep (2/2)

11 Authorization Server Client GET /Temp Temp

Resource representation pre-signed with P's private key

On-the-fly symmetric encryption with key derived from access-secret

Access-secret A Acce ss-se cre t A . . . Temp Humidity . . . Location .well-known/core Access-secret A Access-secret B Access-secret N Producer P CO

(12)

CoAP + OSCAR

12

• CoAP + OSCAR features:

•  Group communication i.e. multicast support

•  Asynchronous message exchanges

•  Proxy and caching capabilities

•  Low overhead

•  Header mapping to HTTP

•  End-to-End Security

•  Authorization and Access Control

✓

±

✓

(13)

Sensor-side Total Energy Consumption

13 3.0 4.0 5.0 6.0 7.0 8.0 9.0 1 3 2 3 4 3 8 3 16 3 S er v er T o ta l E n er g y Co n su m p ti o n ( ⇥ 10 4 mJ) Clients/Session Slots DTLS-Lithe OSCAR = 30s OSCAR = 60s OSCAR = 120s 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 2.1 1 3 2 3 4 3 8 3 16 3 S er v er T o ta l E n er g y Co n su m p ti o n ( ⇥ 10 4 mJ) Clients/Session Slots DTLS-Lithe OSCAR = 30s OSCAR = 60s OSCAR = 120s

WiSMote

(MSP430)

ST GreenNet

(ARM Cortex M3) Lower is better Lower is better

(14)

Conclusions & Future Work

14

• E2E security and authorization framework that supports application

requirements

• E2E security even in presence of application-level gateways

• Particularly useful for use-cases where high number of clients

per sensor is expected

•  Smart city a very good example

• Future extensions

•  Use-cases that require streaming where constant digital signing is unfeasible