and possibly acting on multiple nodes at the same time can, therefore, be far more convenient by cutting down management costs and minimizing the time required for the re-configuration of Smart Objects.
One final remark, related to energy consumption, is the fact that the analysis in Subsection 5.5.2 is performed using the HMAC-SHA1 signature scheme. The OAuth protocol specification considers also the use of the RSA-SHA1 signature scheme, which requires much higher processing load as it relies on asymmetric cryptographic primitives and introduces also the problem of public key management. The amount of processing load (and, thus energy consumption) considered in Fig. 5.5 is then underestimated.
In conclusion, the delegation approach can significantly improve and simplify the design and deployment of Smart Objects, allowing to focus on the fundamental func-tionalities that a constrained node should implement, rather than dealing with other aspects that could be easily outsourced with minimum impact on the development of the application. The use of IoT-OAS does not necessarily forbid or discourage an in-node implementation of authorization functionalities, which might be suited for smart objects with sufficient resources and capabilities. IoT-OAS can be applied effectively in several scenarios, with different network configurations and Smart Object capabil-ities. For instance, being aware of energy consumption issues, IoT-OAS can be used by network elements that do not present the same constraints of smart objects (e.g., LoWPAN border routers, LBRs, which can be connected to a fixed energy supply), as shown in Fig. 5.3(a) and Fig. 5.3(b). Such elements can apply access policies and filter incoming requests, in order to “shield” the constrained network, while allowing the Smart Objects to keep their implementation.
5.6.1 Security Issues
The use of Internet protocols and the very nature of Smart Objects raise security issues in the proposed IoT-OAS architecture. The interested reader is referred to [86]
for an overview of security threats in IoT.
First, delegation to a third party service requires a strong trust on the third party.
The trust relationship between a Smart Object and the IoT-OAS is actually a trust rela-tionship between the owner of the Smart Object and the IoT-OAS. The establishment of such trust relationship falls beyond the scope of this work, which describes the service architecture to which the Smart Objects subscribe. A strongly secure commu-nication channel, such as a VPN tunnel, could be a suitable solution to provide secure and authenticated communications with the authorization service.
The use of standard Internet security protocols can have a negative impact on the performance of Smart Objects, as the communication overhead and computational cost might dramatically affect the energy consumption. In order to tackle these issues, the following actions may be taken:
• define constrained versions and implementations of the security protocols, in order to make the handshaking phase lighter and to minimize packet fragmen-tation;
• define a constrained version of the OAuth protocol, in a similar fashion to what is being carried out in the IETF CoRE Working Group with the definition of the CoAP protocol (with respect to HTTP);
• define new cryptographic suites for the security protocols by integrating lightweight cryptographic algorithms (such as TEA [87], SEA [88], and PRESENT [89]) and lightweight hash functions (such as DM-PRESENT [90] and SHA-3 [91]), which may be more suitable for constrained devices.
Other security aspects might be related to the following possible attacks that smart objects might undergo.
• Denial-of-Service (DoS) might occur if Smart Objects receive a large number of requests to serve. In this case, the use of the IoT-OAS would decrease the
ability of the Smart Object to resist against this type of attacks. A solution could be to use the gateway to protect the Smart Object, possibly by offering caching capabilities.
• Man-in-the-Middle (MITM) attacks are possible if using a HTTP/CoAP proxy
— which, by its nature, is a man-in-the-middle — thus destroying any form of end-to-end security. If the proxy is not trusted, it could access all communica-tions among the endpoints and could possibly get access to the authorization information, thus gaining permission to spoof the requestor’s identity.
• Physical threats are related to the impossibility to supervision constantly Smart Objects once they have been deployed in public/remote areas.
The considerations above are not strictly related to the IoT-OAS architecture, but are typically related to all IoT scenarios and are currently being investigated. How-ever, even though they fall outside the scope of this work, it is important to cite them as open issues. It is also important to remark that the IoT-OAS architecture is not a solution for security aspects in IoT, but, rather, is meant to provide an authorization layer which is easy to integrate and manage for Internet and IoT services.
5.6.2 Computational and Storage Overhead
The OAuth protocol has been designed to handle computation and storage overhead while providing a standard and simple authorization mechanism for resource access by third-party applications. The same considerations can be applied to our approach, as there is no computation and storage on the node, but all the information resides on the central authorization service. Typical examples of the scalability of OAuth-based services are online social networks, such as Twitter and Facebook, which deal with hundreds of millions of users, billions of requests, and several thousands of third-party applications which access the hosted resources. The above considerations are confirmed by the performance evaluation of the IoT-OAS architecture in Section 5.5:
i) the memory footprint of all software modules that should be run on the Smart Object leaves no space for the storage of user identities and access policies (as shown
in Fig.5.7); ii) from a processing perspective, the Smart Object does benefit from a delegation approach, as there is no computation to be performed besides sending a request to the IoT-OAS.