An IoT infrastructure needs to be secured, in order for people to trust it, and to prevent attackers from compromising the security and privacy goals of the applications deployed in the infrastructure.
This deliverable extends the requirements defined in D2.4, and makes them more precise, by taking into account the experiences from IT-1, the planned work for IT-2 (numerous targets were considered out of scope for IT-1), and recent industry and academic research.
The security components developed for IT-1 were sufficient to validate the basic design, of using agent-based security supported by public/private keys, where the public keys were signed by an authority that was deployed in the cloud. Additional components developed for IT-1, but in the end not integrated into it, highlighted additional issues which are still largely unresolved, the first of which is how to obtain a consistent implementation of the security model across all components, without re-inventing the wheel. In particular, the need for message-based and channel (socket) based security was raised (features that come out of the box when using SOAP but are much harder with REST), as well as whether we should encrypt stored data. The answer seems to be that mF2C use cases need both message-based and socket-based security, but encrypting stored data is not a good idea because key management is hard and does not seem suited to a fog architecture.
This deliverable describes in some length secure-by-design software development (greatly extending the corresponding section of D2.4). Certainly, not all software in IT-1 was developed under this principle, and following all the recommendations would triple the length of the project, so priorities need to be set. These need to be set after D3.2 and D4.2 have been finished, with the proposed implementations of the security requirements set out here.
Other issues that were postponed from IT-1 include the physical security of the devices, where, based on industry “solutions,” it would make sense to at least investigate a few of the options provided by the industry, as well as current practices for implementing tamper-resistant or tamper-evident devices, so in turn the project can make recommendations to parties that wish to make use of the mF2C results. Physical security of the edge and fog devices is a particular concern in UC2, but also UC1, albeit to a lesser extent.
Another requirement revealed by the analysis of use cases is the need – somewhat contrary to earlier plans – to support application security on the mF2C framework. This, if implemented, would need to be done using the same code as used by the platform (itself re-engineered from the code developed before IT-1), but using different keys, so a compromised application would not compromise the rest of the infrastructure.
Beyond this, there are opportunities to do more research-type work into security applications of blockchains and machine learning. Like the physical security mentioned earlier, this work should be able to happen in parallel with the implementation of the security which will be proposed in D3.2 and D4.2, with only relatively few dependencies between the areas. As initially outlined in D2.4, there is now an opportunity to make good on the promise that deliverable to investigate acting on the monitoring data to automatically handle security incidents, without blocking legitimate activity that will look similar, such as an emergency in UC1.