Grant no * REliable, Resilient and secUre IoT for sMart city applications 1

Grant no RERUM key tangible outcomes  RERUM Security/Privacy Architecture  DTLS  CS encryption  Integrity Protection (Digital Signatures)  Privacy-Enhanced Tokens for Authorization in ACE 2

Grant no RERUM Domain model 3 New cmp. IoT-A:  RD  VRD  GVO  Context (like in BUTLER)  Administrator  Policies  Data subject  Human User  Consent  Trust/reputation

Grant no Security/Privacy 4 Security Privacy Confidentiality Protection (DTLS & CS & RSSI-key) Integrity Protection (MAC & DTLS & ECDSA Sign) Authorization and Access Control Secure Credential Bootstrapping PRRS capabilities (incl.OAP) and SIEM integration Privacy Policies and its enforcement PET for Geo-Location Pseudonyms and related mechanisms (e.g. PAT-Token) Privacy Dashboard + Consent Manager Privacy Enhanced Integrity Protection (MSS) ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Grant no RERUM Architecture 5

Grant no RERUM Privacy architecture 6

Grant no Security/Privacy on the RDs - DTLS Datagram Transport Layer Security (DTLS) DTLS protects confidentiality and integrity of communication Asymmetric keys also allow identifying the origin DTLS implemented on RE-Mote on Contiki OS using TinyDTLS 7

Grant no Security/Privacy on the RDs - DTLS 8  Mutual Certificate based Handshake  Proposition to use Curve25519 (ECDH) and Ed25519 (Sign)  ECC is lightweight  Possibility of h/w acceleration for ECC on the RE-Mote

Grant no Security/Privacy on the RDs - DTLS 9

Grant no Security/Privacy on the RDs - CS  Simultaneous compression and encryption  Lightweight encryption on the device  Adaptive to changes in signal pattern  Lossy encryption – reconstruction error at the receiver 10

Grant no Security/Privacy on the RDs - CS  Client implementation on Contiki OS  Requires encryption key  Compression rate  Can be either stored or generated  Is implemented as a CoAP resource  Server implementation on Java  Should have/generate the same key  Estimates the original measurements  Minimize reconstruction error  Identifies signal changes and requests new compression rate 11

Grant no Security/Privacy on the RDs - Signatures  Implemented  based on micro-ECC library for RE-Mote  currently ECC curve from NIST (future: ed25519)  also worked on Z1  JSS: Signature Container for JSON data  signature over JSON retained from RD-to-OTHER  Integrity of sensed data verifiable in GW or MW  End-to-End Integrity protection, Origin authentication 12

Grant no Security/Privacy on the RDs - Signatures 13

Grant no IETF draft  Privacy-Enhanced Tokens for Authorization in ACE 14

Grant no PRIVACY-ENHANCED TOKENS FOR AUTHORIZATION IN CONSTRAINED ENVIRONMENTS D. Calvo, J.Gato - Atos Research & Innovation J.Cuellar, P. Kasinathan, Santiago Reinhard - Siemens AG IoT Week Belgrade 15 Reliable, Resilient and Secure IoT for Smart City Applications Grant no Restricted

Grant no Objectives  Definition of a protocol to create secure communication channels in constrained environments  Authorization  Integrity  Privacy & Confidentiality  DoS Resilience  Efficiency is the key!!  Low energy consumption: extended battery life  Minimum impact in resources usage 16

Grant no Constrained Environments  Personal Health Monitoring 17

Grant no Authorization Problems  Personal Health Monitoring  Special access rights are defined for emergencies  Restricted access to medical data for different persons  Constant operation: opportunity for DoS attacks  Integrity and confidentiality of the data are ensured 18

Grant no Constrained Devices  Zolertia RERUM Re-Mote 19 ARM Cortex-M3 32 MHz 512 KB flash 32 KB RAM Consumption down to 150 nA using the shutdown mode Built-in battery charger (500 mA) ISM 2.4-GHz IEEE & ZigBee compliant radio ISM MHz ISM/SRD band IEEE compliant radio

Grant no Architecture: Collocated CAM-C 20 Authorization Server (AS) CLIENT (C) SERVER (S) Safe Channel (DTLS) No-confidential channel

Grant no Protocol overview: Tokens 21

Grant no Unauthorized Resource Request [C->S] 22  Client knows Resource Server and Server  Client doesn’t know who is the SAM  Client performs a request without Ticket CLIENT (C) SERVER (S) COAP: GET ECG

Grant no SAM Information Message [S->C] 23  Client does not have access ticket  Response Code: Unauthorized  SAM Information: URI, timestamp CLIENT (C) SERVER (S) COAP: 4.01 SAM URI Timestamp

Grant no Authorization SERVER (S) Access Request Message [C->AS] 24  Client already knows SAM  Resource URI & Actions to perform CLIENT (C) DTLS : POST coaps://server/AUTHORIZE RESOURCE URI GET&PUT S Timestamp

Grant no Construction of Token in AS 25  Face Data: Resource URI & Operations Allowed Time Stamp Lifetime Random value  Verifier: HMAC(K, Face Data) [Poly1305] K: long term secret shared between SAM & S

Grant no Authorization Server (S) Ticket Transfer Message [AS->C] 26  Token:  Face Data  HMAC (K, Verifier) [Poly1305]  Verifier CLIENT (C) DTLS: 2.01 Token Verifier

Grant no Authorized Resource Request [C->S]  Client has a valid Access Token  Safe channel (DTLS) is not required  Payloads are encrypted  ChaCha20_Poly1305_AEAD with Verifier as Key  Client attaches Face to each request CLIENT (C) SERVER (S) COAP: GET ECG Token

Grant no Validation of Access Tickets in Server  Access ticket: Face Data & HMAC (K, Verifier)  Verifier was built by AS: HMAC(K, Data) [Poly1305]  S generates its own version of Verifier and checks the Hash contained in the Access Ticket  C demonstrates Verifier PoP => Resilience against DoS attacks  S checks Face Data validity  Resource & Operations  Time Stamp & Life Time

Grant no Valid Response [S->C]  Payloads are encrypted  ChaCha20_Poly1305_AEAD authenticated encryption mechanism CLIENT (C) SERVER (S) 2.05 Payload: {Enc(V,resp)}

Grant no Conclusions  Efficient communication C S  AEAD_CHACHA20_POLY1305 OTK Privacy & Confidentiality Integrity  Length(cipherText)= Length(plainText)  Authorization delegated to unconstrained AS  Authenticated Encryption and PoP  Resilience to DoS attacks

Grant no Roadmap OCTOBER 2015 Draft standard v2 raft-cuellar-ace-pat-priv- enhanced-authz-tokens-02 MARCH 2016 Java prototype gitlab.atosresearch.eu JUNE 2015 Draft standard v1 raft-cuellar-ace-pat-priv- enhanced-authz-tokens-01 JULY 2016 IETF Berlin Meeting ortant-dates html#ietf96 APRIL 2016 Draft standard v3 raft-cuellar-ace-pat-priv- enhanced-authz-tokens-02

Grant no Main people involved  Jorge Cuellar - Siemens  Prabhakaran Kasinathan - Siemens  Santiago Reinhard Suppan - Siemens  Daniel Calvo - ATOS 32

Grant no Acknowledgements The RERUM project has received funding from the European Union’s Seventh Programme for research, technological development and demonstration under grant agreement No ) 33

Grant no Questions? THANK YOU!! Daniel Calvo Atos Research & Innovation IoE Lab booklet.atosresearch.eu