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

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

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

4. Grant no. 609094 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) ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

5. Grant no. 609094 RERUM Architecture 5

6. Grant no. 609094 RERUM Privacy architecture 6

7. Grant no. 609094 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

8. Grant no. 609094 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

9. Grant no. 609094 Security/Privacy on the RDs - DTLS 9

10. Grant no. 609094 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

11. Grant no. 609094 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

12. Grant no. 609094 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

13. Grant no. 609094 Security/Privacy on the RDs - Signatures 13

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

15. Grant no. 609094 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 2016 - Belgrade 15 Reliable, Resilient and Secure IoT for Smart City Applications Grant no. 609094 Restricted

16. Grant no. 609094 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

17. Grant no. 609094 Constrained Environments  Personal Health Monitoring 17

18. Grant no. 609094 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

19. Grant no. 609094 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 802.15.4 & ZigBee compliant radio ISM 863.950.MHz ISM/SRD band IEEE 802.15.4 compliant radio

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

21. Grant no. 609094 Protocol overview: Tokens 21

22. Grant no. 609094 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

23. Grant no. 609094 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

24. Grant no. 609094 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

25. Grant no. 609094 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

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

27. Grant no. 609094 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

28. Grant no. 609094 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

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

30. Grant no. 609094 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

31. Grant no. 609094 Roadmap OCTOBER 2015 Draft standard v2 https://tools.ietf.org/html/d raft-cuellar-ace-pat-priv- enhanced-authz-tokens-02 MARCH 2016 Java prototype gitlab.atosresearch.eu JUNE 2015 Draft standard v1 https://tools.ietf.org/html/d raft-cuellar-ace-pat-priv- enhanced-authz-tokens-01 JULY 2016 IETF Berlin Meeting http://ietf.org/meeting/imp ortant-dates- 2016.html#ietf96 APRIL 2016 Draft standard v3 https://tools.ietf.org/html/d raft-cuellar-ace-pat-priv- enhanced-authz-tokens-02

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

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

34. Grant no. 609094 Questions? THANK YOU!! Daniel Calvo daniel.calvo@atos.net Atos Research & Innovation IoE Lab http:// booklet.atosresearch.eu