application layer security protocols for the iot - sics · pdf fileapplication layer security...

Application Layer

security protocols for the IoT

Göran Selander, Ericsson Research SICS Security Day, Sept. 07, 2017

Slide title 44 pt

Text and bullet level 1 minimum 24 pt

Bullets level 2-5 minimum 20 pt

Characters for Embedded font: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚěĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞşŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻż��ƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅỲỳ–—‘’‚“”„†‡•…‰‹›⁄€™ĀĀĂĂĄĄĆĆĊĊČČĎĎĐĐĒĒĖĖĘĘĚĚĞĞĠĠĢĢĪĪĮĮİĶĶĹĹĻĻĽĽŃŃŅŅŇŇŌŌŐŐŔŔŖŖŘŘŚŚŞŞŢŢŤŤŪŪŮŮŰŰŲŲŴŴŶŶŹŹŻŻȘș−≤≥fifl

ΆΈΉΊΌΎΏΐΑΒΓΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΪΫΆΈΉΊΰαβγδεζηθικλνξορςΣΤΥΦΧΨΩΪΫΌΎΏ

ЁЂЃЄЅІЇЈЉЊЋЌЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯЁЂЃЄЅІЇЈЉЊЋЌЎЏѢѢѲѲѴѴҐҐәǽẀẁẂẃẄẅỲỳ№

Do not add objects or text in the

footer area

Göran Selander | Ericsson | 2017-06-08 |

Standardization LANDSCAPE

Slide title 44 pt







footer area


Analysts' views oF IOT SECURITY

› Gartner: IoT Security at the top of 10 IoT technologies for 2017 and 2018 ›  “IoT security will be complicated by the fact that many ‘things’ use simple processors and operating systems that may not support sophisticated security approaches.”

› Forrester Research: TechRadar™: Internet Of Things Security, Q1 2017 › "The 13 most relevant and important technologies for delivering internet of things (IoT) security."

› 6 of these on trajectory "significant success", rated according to "business value add, adjusted for uncertainty" ordered from "major" to "medium" à next 2 slides

Slide title 44 pt







footer area


ForRESTER / FORBES ON IOT SEC. 1.  IoT network security:

Protecting and securing the network connecting IoT devices to back-end systems on the Internet. "more challenging than traditional network security because there is a wider range of communication protocols, standards, and device capabilities"

2.  IoT authentication: Providing the ability for users to authenticate an IoT device "many IoT authentication scenarios (such as embedded sensors) are machine-to-machine based without any human intervention"

3.  IoT encryption: Encrypting data at rest and in transit between IoT edge devices and back-end systems using standard cryptographic algorithms "The wide range of IoT devices and hardware profiles limits the ability to have standard encryption processes and protocols."

Slide title 44 pt







footer area


ForRESTER / FORBES on IOT SEcurity

4.  IoT PKI: Providing complete X.509 digital certificate and cryptographic key life-cycle capabilities "hardware specs for some IoT devices may limit or prevent their ability to utilize PKI. "

5.  IoT security analytics: providing actionable reporting and alerting on specific activities or when activities fall outside established policies.

6.  IoT API security: Providing the ability to authenticate and authorize data movement between IoT devices, back-end systems, and applications using documented REST-based APIs.

Slide title 44 pt







footer area


ForRESTER / FORBES on IOT SEcurity

Forrester makes the following observations and recommendations:

›  IoT security requires an end-to-end approach; › Encryption is an absolute must; ›  IoT security scenarios place a premium on scalability (dealing with the sheer number of devices);

› Security analytics will play a significant role in IoT security solutions; ›  IoT standards are important catalysts but still need time to mature.

Slide title 44 pt







footer area


end-to-end SECURITY

A.  Through intermediaries, e.g. store-and-forward

B.  Across different transport layers, e.g. last hop non-IP

C.  End-to-end REST, e.g. HTTP client – CoAP server

TCP

Client Capillary

GW SMS

Center Cellular

GW Server

Client Server

Fowarding Proxy

SMS UDP Link

Client Server

Translational Proxy

HTTP CoAP

Slide title 44 pt







footer area


Security at Different Layers

Intermediaries can modify HTTP/CoAP headers

Intermediaries cannot read HTTP/CoAP headers

Intermediaries can read but cannot modify headers

Candidate security layers

UDP/TCP

Application

IP

HTTP/CoAP

Link

Long

er s

ecur

e ho

ps

TLS

IPsec

Slide title 44 pt







footer area


SCALABLE to large numbers

› Generic security enablers › Suitable for unconstrained as well as very constrained devices

– Restriced in CPU, RAM, ROM, Power, Lack of UI, ...

› No compromise on security; state-of-the-art encryption etc.

› Align with relevant IoT standards: –  IETF CoAP suite – OMA DM LWM2M –  IPSO Smart Objects

Low security overhead is always desirable even if devices are not constrained.

- Crypto computation is not necessarily an issue - Message overhead is in many cases an issue

à Message size à No. of round trips

Used e.g. by IKEA Trådfri

Slide title 44 pt







footer area


examples of IOT SECURITY Standardization in the iETF

End-to-end security

OSCOAP secures unicast or multicast with unicast response ›  COSE – Secure message format based on CBOR

–  CBOR is a compact data encoding format optimized for lightweight parsing in constrained devices

›  OSCOAP – Authentication, encryption, integrity and replay protection for CoAP

1.  Wrap the CoAP messages in COSE format 2.  Send the COSE object with CoAP

›  ACE – Lightweight authorization and access control; a version of OAuth 2.0

1.  Client acquires access token from authorization server 2.  Client presents access token to resource server to get access

›  EDHOC – Key exchange protocol messages embedded as CBOR and COSE, and sent e.g. with CoAP

–  Establish session keys with perfect forward secrecy ›  EALS – Certificate enrolment using these application layer

security protocols Client

Authorization Server

Resource Server

2. Access Token

1. Authorization Request

3. Request + Token

Slide title 44 pt







footer area


COncise BINARY OBJECT REPRESENTATION (CBOR)

› "CBOR is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation."

› CBOR playground: http://cbor.me/

0 0x00 1 0x01 23 0x17 24 0x1818 -1 0x20 -10 0x29 -100 0x3863 0.0 0xf90000 1.0 0xf93c00 -4.0 0xf9c400 h'' 0x40 h'01020304' 0x4401020304 "" 0x60 "a" 0x6161 [] 0x80 [1, 2, 3] 0x83010203 {} 0xa0 {1: 2, 3: 4} 0xa201020304

Slide title 44 pt







footer area


›  COSE describes how to create and process signatures, MACs and encryption, and also how to represent keys, using CBOR for serialization.

CBOR OBJECT SIGNATURE and ENCRYPTION (COSE)

Headers

Payload

Signature

COSE_Sign1

Headers

Ciphertext

COSE_Encrypt0

Algorithm, Key Identifier, … Algorithm, Key Identifier, … [ h’a10126’, {4:’11’},’Hello World’, h’e2aeafd40d69d19dfe6e5 2077c5d7ff4e408282cbefb 5d06cbf414af2e19d982ac4 5ac98b8544c908b4507de1 e90b717c3d34816fe926a2 b98f53afd2fa0f30a’ ]

\ alg \ 1:-7 \ ECDSA 256 \

/ kid / 4:’11’

Signature

Payload

Slide title 44 pt







footer area


Object Security of COAP (OSCOAP)

CoAP UDP

CoAP CoAP TCP

CoAP

Client

Capillary GW

SMS Center

Cellular GW

SMS BLE

Server

End-to-endsecurity

›  Supports notifications (Observe) and fragmentation (Block) schemes defined for CoAP

›  Can be extended to secure CoAP group communications

›  A security extension to CoAP ›  Defined in terms of CBOR and COSE ›  End-to-end security for CoAP over any/mixed

transport (UDP, TCP, SMS, BLE, ...) ›  Supports CoAP proxy forwarding operations,

and HTTP-CoAP proxy functionality

Slide title 44 pt







footer area


›  Provides end-to-end confidentiality, integrity and replay protection

›  Protects CoAP messages using the COSE_Encrypt0 format

›  Authenticated Encryption with Additional Data (AEAD)

›  AES-CCM with 128 bit key/64 bit MAC is mandatory to implement

›  Encrypts all parts of the CoAP message not intended for a proxy

›  Can be used together with or instead of DTLS

›  Is lightweight, e.g. in terms of message overhead, RAM, ROM

Client Server

AEAD Encryption

AEAD Decryption

OSCOAP additions to CoAP

processing

Creating the CoAP request

CoAP processing and creating Response

AEAD Encryption

AEAD Decryption

Processing the CoAP response

Response is bound to the request

OSCOAP details

Slide title 44 pt







footer area


OSCOAP message overhead Protocol Overhead (B) for

Sequence Number = '05' Overhead (B) for

Sequence Number = '1005'

Overhead (B) for Sequence Number =

'100005'

DTLS 1.2 29 29 29 DTLS 1.3 21 21 21 TLS 1.2 21 21 21 TLS 1.3 21 21 21 DTLS 1.2 (GHC) 16 16 17 DTLS 1.2 (Raza) 13 13 14 TLS 1.3 (GHC) 14 14 15 TLS 1.3 (Raza) 13 13 14 TLS 1.2 (GHC) 17 18 19 TLS 1.3 (GHC) 17 18 19 OSCOAP Request 13 14 15 OSCOAP Response 9 9 9

Slide title 44 pt







footer area


Authentication and Authorization in Constrained environments (ACE)

› Generic problem: A Client wants to access resources on Resource Server (RS)

›  E.g. using a REST-based protocol ›  How can the client become authorized, authenticate and

prove to the RS that it is, and then get access? ›  IoT setting: Client and RS may be constrained, have

intermittent connectivity, lost time synchronization, etc. ›  The ACE Framework defines a version of OAuth 2.0

suitable for IoT ›  Profiles of the ACE framework define different

communication and security schemes between Client and RS to support different IoT deployments

›  DTLS profile, OSCOAP profile, MQTT profile, etc.

Client

Resource Server

REST = CoAP

Slide title 44 pt







footer area


Client Authorization Server

Resource Server

Resource Owner

2. Access Token

1. Authorization Request

0. Configure Access Control Policies 3. Request

+ Token

Authentication and Authorization in Constrained environments (ACE)

Slide title 44 pt







footer area


Key establishment

› Generic problem: Endpoints require to establish keys in to authenticate each other

›  Alt 1. A trusted third party, such as the ACE Authorization Server, provides keys

›  Alt. 2. A key exchange protocol, such as EDHOC, can be used to establish keys with forward secrecy

›  Authentication can be based on Pre-Shared Keys, Raw Public Keys or X.509 Certificates

Client Server

Authorization Server

Alt. 1

Alt. 2

Slide title 44 pt







footer area


SUMMARY

› Many IoT security challenges remain relevant ›  New application layer security protocols suitable

for constrained environments are being standardized in the IETF, addressing things like

›  end-to-end security through intermediates ›  authentication, authorization & key

establishment ›  key exchange ›  certificate enrolment

•  https://www.forbes.com/sites/gilpress/2017/03/20/6-hot-internet-of-things-iot-security-technologies •  CBOR – https://tools.ietf.org/html/rfc7049 •  CoAP – https://tools.ietf.org/html/rfc7252 •  COSE – https://tools.ietf.org/html/rfc8152 •  Use Cases for Authentication and Authorization in Constrained Environments – https://tools.ietf.org/html/rfc7744 •  OSCOAP – https://tools.ietf.org/html/draft-ietf-core-object-security •  ACE Framework – https://tools.ietf.org/html/draft-ietf-ace-oauth-authz •  CoAP/DTLS profile for ACE – https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize •  OSCOAP profile for ACE – https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile •  Pub/Sub profile of ACE – https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-profile •  Secure Group Communication for CoAP – https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap •  EDHOC – https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe •  EALS – https://tools.ietf.org/html/draft-selander-ace-eals •  6tisch Minimal Security – https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security •  Requirements for CoAP e2e Security – https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs

selected References

Slide title 44 pt







footer area


OSCOAP extends to groups

Broad-caster

Listener

Listener

Listener

Multicast request

Unicast responses

APPLICATION: OSCOAP IN 6.sch join

uses EDHOC (optional)

unprotected

6TiSCH@IETF97

uses OSCOAP (with PSK

payload 4: 15 bytes payload 5: 26 bytes)

application layer security protocols for the iot - sics · pdf fileapplication layer security...

Documents