PLUG-N-HARVEST ID: 768735 - H2020-EU.2.1.5.2. WP3 - Task 3.4: Operational Security Mechanisms ORGANIZATION: Odin Solutions/OdinS PRESENTER(S): Antonio Skarmeta MEETING: Kickoff Meeting, Aachen, 21-22 September 2017 November 24, 2018 PLUG-N-HARVEST ID: 768735 - H2020-EU.2.1.5.2.

Task 3.4 Operational Security Mechanisms Lead OdinS – Contributors: CERTH, SIEMENS, ETRA Develop protocols attest and monitor the infrastructure and correct handling of data according to the given policy. Defining fine-grained access control for privacysensitive data, providing tools for allow a user-centric approach, allowing user the access policy Integration of data minimization techniques to control de level and exposition of certain attributes and/or data generated by smart devices will be envisaged. Attribute-based encryption (ABE) schemes for fine-grained access control without a lengthy user authorization process and its integration with minimal disclosure technologies How content-centric security can be applied to data and information to provide end-to-end security, but in such a way that it minimises the exposure of such data PLUG-N-HARVEST ID: 768735 - H2020-EU.2.1.5.2.

Main Security and Privacy aspects Protect infrastructure elements for possible threats: Securre communications and Access control mechanism integration with the ADBE and IMCS/OEMS solutions Integrated authorization mechanism XACML Policies based to specify privacy policies on structural models describing both users and applications properties; a distributed access control model based on capabilities tokens will be provided to manage the authorization access; Privacy preserving solutions a privacy-preserving identity management solution to be linked with the IdM framework a privacy preserving group communication solution based on CP-ABE. PLUG-N-HARVEST ID: 768735 - H2020-EU.2.1.5.2.

IoT at glance Data’s producer to be sent through intermediate nodes until they are received by consumers The challenge is to guarantee S&P between producer(s) and consumer(s)

The problem To guarantee producer-to-consumer (end-to-end) S&P, so the crypto approach must take into account: Performance: to be accommodated (even) in devices with resource constraints IETF RFC 7228: Terminology for Constrained-Node Networks It is not about to fit crypto in constrained devices at any price: For example, how often will be required a certain crypto algorithm to be performed?

Addressing IoT Security and Privacy challenges Architectural Challenges IoT under constant (r)evolution  the consequence is a fragmented landscape of solutions and technologies Need for defining architectures abstracting from underlying technologies Security and Privacy are not considered as first-class components Increasing interest from different standardization organizations AIOTI WG03 – “High Level Architecture (HLA)” IEEE (P2413) – “Standard for an Architectural Framework for the IoT” oneM2M Functional Architecture ITU-T (Y.2060) – “Overview of the Internet of Things” ITU-T (SG20) – “IoT and its applications including Smart cities and communities” Recent European iniatives (SENSEI, BUTLER,…) addressing specific use case or scenarios based on architectures at different abstraction levels

Addressing IoT Security and Privacy challenges Technical Challenges From Security Extension for identity management schemes to smart objects Fine-grained delegation-based access control and simplified key management Preservation of security properties on resource-constrained devices (E2E security) From Privacy Support of privacy directives (GDPR) and Privacy By Design (PbD) principles Support for minimal or selective PII disclosure User control on data sharing or outsourcing of PII Scalability Flexibility Interoperability

Flexible and Lightweight Authorization for IoT Motivation Current approaches, (e.g. OAuth 2.0), mainly focused on Web scenarios… … and bearer tokens lack Proof-of-Possession (PoP) mechanisms Solution: Distributed Capability-Based Access Control (DCapBAC) Foundations SPKI Certificate Theory – binding access rights to a public key ZBAC, Policy Machine from NIST Design Authorization token following a similar semantics to JSON Web Tokens (JWTs), but: Including access rights as <action, resource> pairs associated to a cryptographic key Conditions to be verified by the enforcer Use of technologies for IoT (e.g. CoAP, DTLS, ECC) Integration with XACML and PoP mechanisms for privacy-preserving purposes

Access Control in the IoT Motivation Lack of inclusive approaches going beyond authorization covering authentication, identity management or group management aspects Direct access vs Platform-based access

Flexible and Lightweight Authorization for IoT DCapBAC extended scenario (client initiated)

Integration with dynamic and privacy-preserving aspects Motivation Use of the public key within the token prevents C’s privacy to be preserved Need for PoP mechanisms that support minimal disclosure Solution Use of partial identities as a subset of attributes from the whole identity Binding privileges to a partial identity Access rights of DCapBAC tokens associated to a partial identity (or pseudonym) Instantiation through different cryptographic schemes (based on challenge-response) IBE: the key is associated to the pseudonym within the token CP-ABE: key’s attributes to satisfy the partial identity Anonymous credentials (Idemix): based on a proof derived from the anonymous credential

Security and Privacy Framework for the IoT Operation Performing tasks for which it was manufactured Pair operation vs Group operation Pair operation Enabled by authorization credentials obtained through the infrastructure Instantiation based on DCapBAC tokens and privacy-preserving proof of possession Group operation Instantiation based on CP-ABE

Use Case 24/02/2017 Final Review