An mF2C infrastructure must implement security, and we propose here a security policy comprising three levels of data protection:
Public for data requiring no special protection,
Protected for data which needs to be integrity protected but is not confidential, and
Private for data which needs both integrity and confidentiality protection.
The best way of implementing this is to tag data with the required security level – as determined by the sender (or owner) of the data.
This deliverable discusses how the security requirements for the architectural layers that were identified in D2.4 implement and support the security policy. Likewise, each of the functional blocks identified for agents map to requirements which also build on the policy. For example, the requirement for service discovery is linked to the Protected category, as services are usually not secret, but endpoints need to be integrity protected in order to prevent an attacker from impersonating a service, or from maliciously advertising their own services.
This deliverable highlights the need for multipurpose messages, that can carry (say) confidential information along with public, or confidential information from several recipients – there are several such protocols but we are not aware of any used in an IoT scenario. Related challenges arise when lightweight devices – or devices from outside the control of mF2C – communicate data into mF2C; in this case, mF2C must infer ownership and protection requirements. Moreover, other interesting challenges arise when data is processed; if Private data belonging to different individuals is processed, who owns the result? Further challenges arise from the mobility of devices – e.g. if the same device fulfils different roles in mF2C at different times, and from the potentially limited capacity of devices, which may require supplementary services, e.g. that the recipient of data takes (some) responsibility for the policy, or for providing loosely coupled security services to support agents in the fog.
This deliverable highlights these challenges, which are challenges for both the use cases and for the implementation of mF2C in general.