ON THE SECURITY AND PRIVACY OF INTERNET OF THINGS ARCHITECTURES

Editor's Notes

• #2: (30 sec)
• #3: 30 sec Say about, why choose these architectures?
• #4: 1.5 minutes Talk about not only at level of device but overall iot ecosystem
• #5: Add bullet requirements derived from properties Show main level -> then sub reqts No “we check”! Say more about privacy and trust 1.5 minutes Give egs to explain the sub reqts avoid defn! Shift teh image up Make eg of a automated bus statio
• #6: 10 sec
• #7: (2 – 2.5 min) IoT-A, namely IoT architecture provides an architectural reference model as mainly guidelines for the network protocols of iot architectures. Also provides mechanisms for integrating the ARM to service into IoT. This is an EU funded project which was completed in 2013. KEM -> manages the cryptographic keys that are used for conf. And integrity in combn with authenticity. However, KEM doesnt address availability in the context of the network connections. IM is being addressed by three components namely IM, AuthZ and AuthN. AuthN module covers the authentication reqts for the user and service as well as accountability with non repudiation (assurance that someone cannot deny something). AuthZ module cover the authorization via access controls namely role based (RBAC) and attribute based access control (ABAC). Revocation depends on the ACM used. Accountability doesnt seems to be addressed by any of these security comp in IM. Pseudonymisation security (PN) componet addresses our privacy requirements. As the name suggests IoT-A replaces original identities obtained KEM by pseudonyms. It used different pseudonyms different actions that accounts for unlinkability. It doesnt seems to address anonymity on the whole. And, data privacy is not addressed by the PN component however, some means of access granurality is provided by AuthZ. Trust and reputation component provides device and entity trust but data trust in particular is not addressed. (collection of user reputation to calculate service trust) Outside the security functional group, fault tolerance is done as a separate functional group called fault handling-> is divided into four func components namely predicting the potential failures, detecting existing failures, reduction of effects of failures and repairing the system. So first address our first requirement of robustness against attacks and latter three the other ie. Resilience against attacks.
• #8: (2 – 2.5 min) First, the Physical Layer contains the M2M systems connected to the platform. Second, the Adaptation Layer handles the connection to the physical layer, abstracting from peculiarities of the individual M2M systems. The third layer, namely the TaaS Layer, relies on the abstraction layer and provides networkwide access to the devices in the M2M layer. Finally, the Service layer manages the functionalities and services of BeTaaS applications. KM performs authentication, manages user sessions, and provides encrypted communication. Uses pki in combn with CA that ensures conf, integrity and authenticity. Authentication module addresses our IM security requirements by providing two level authentication (gateway level and app or service level auth). Auth module makes use of KM component and Oauth is adapted for authen and author. However, the accountability requirement remains unclear. While Privacy is stated as a key aspect of the security mechanisms in BeTaaS [6], there is no evidence of how this requirement is fulfilled. Trust is handled by Trust & Reputation component. The model retrieves input from individual trust aspects: security mechanisms (which for instance include information regarding the encryption algorithms, the certificates, etc.), QoS fulfillment, dependability performance, battery load and stability in provided data. Lastly, the aspect of resilience is handled via four different pillars: fault prevention, removal, tolerance and forecasting
• #9: (2 – 2.5 min) Opposed to the specification, privacy features are not present in the public code. IPSec tunnels established by gateways to ensure confidentiality, integrity and authenticity. Availability is not mentioned in the context of network security. OpenIoT uses a centralized security and privacy module-> Oauth handles authentication and role based access control model for AuthZ. The fulfillment of further requirements, e.g., accountability, remains unclear. trust module is an independent module in OpenIoT. Addresses the requirements of data and device trust and entity trust remains unclear. OpenIoT does not address robustness in terms of failure avoidance, but rather places the focus on resilience in terms of mitigation
• #10: (2 – 2.5 min) With other Iot arch we have discussed focuses eithr on domestic domain or both domestic and industry domain. Now we discuss Iot@Work that focuses only on industrial automation domain that shifts the security focus also. Privacy and Trust are not driving requirement due to industry focus. Network security is handled mainly mainly by commonly used technologies such as Extensible authentication protocol. However integrity or network integrity is not addressed. The concept of network slices allows for network virtualization, and thus fast network link fail-over to protect availability. Authentication is mainly provided by network security in IoT@Work. Furthermore, authorization is realized via Capability-Based Access Control (CBAC) with support for delegation, accountability, and revocation. CBAC works well with many entities as well as under connection failure to the central authorization service. Some data privacy is provided and access delegation is used for pseudonyms. Anonymity can be achieved by proving capabilities through Zero Knowledge Proofs (ZKPs). The network slice approach uses virtual network links that are robust against failures. In addition, live reconfiguration is possible and thus allows for recovery in the sense of resilience.
• #11: (1 min) Remove highlighting BeTaaS inherits from the high level abstraction reference model of IoT-A. Thus, similarly to IoT-A, access control mechanisms enforce data privacy by restricting unauthorized access. The identity management component is responsible for managing the way identities of sensors or gateways are presented in their interaction with BeTaaS instances. Apart from data privacy being maintained by centralized access control, data anonymization and pseudonymity is not elaborated in OpenIoT The IoT scenarios described in IoT@Work do not introduce a need to deal with trust issues, so the model does not provide any mechanisms to cope with trust
• #12: 1 min