1. 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, September 2017
November 24, 2018
PLUG-N-HARVEST ID: H2020-EU

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: H2020-EU

3. 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: H2020-EU

4. 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)

5. 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?

6. 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

7. 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

8. 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

9. 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

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

11. 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

12. 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

13. Use Case
24/02/2017
Final Review