Reading Time: 2 minutes

While still in its infancy, current IoT deployments often have security weaknesses that have been exploited, from “hackers” who are exploring the system to malicious cybercriminals. Moreover, these exploits have been covered widely in the press and tends to give IoT a bad name.
It is clear that mF2C must do better: without a comprehensive cross-infrastructure approach to security, the outcome of the project will see little practical use and have little chance of surviving beyond the end of the project. As has become (good) practice in FP7 and H2020 projects (having learned from experiences in earlier projects), security is designed in from the proposal, rather than added as an afterthought.
This document describes the background (privacy, data protection, protocols and cryptography) behind securing a distributed infrastructure. We then look at the implications for mF2C, from the point of view of the architecture as it is currently understood, the software components and use cases. No single security “solution” fits all applications – or devices – or budgets – so it must be possible to select the right level and enforce it across the infrastructure. For each such application it is necessary to understand the threats, and the associated risks to the infrastructure. In many situations, the weaker link is the end user, so usability is important, as is the motivation to implement security, which is it not just seen as a hurdle, but an essential part of the service. User protection starts with privacy and enables users to control and monitor how their data is used; with better transparency, users should feel empowered rather than forced to share their data.
This deliverable is submitted at the end of month 4 of the project, so it is necessarily early days – many technical things may change. Nevertheless, its scope is to set out security for the rest of the project, in order that future evaluations and plans are built on it.