14.2.3.1 Threats and Vulnerabilities

In order to secure an IoT application, several points need to be considered:

• Firstly, with the device itself, since those devices apply relatively weak security mechanisms due to their constrained nature, and also they can be either physically accessible or they can simply be malicious. Hence all these possibilities need to be treated, as explained in 14.2.2.

• Then, the different communication protocols used to communicate with the smart devices. Several vulnerabilities appear (such as Ghost attack in ZigBee [22], usurpation, Sybil attack and Sinkhole attack in 6LoWPAN [23], etc.), which can compromise the devices and the infrastructure.

• Next, the threats coming from the external entities. Attacks such eavesdropping, tampering, DoS attacks, phishing attacks or code injection attacks can occur.

• And finally, problems related to the privacy and trust from the device owner perspectives. Naturally private information needs to be confidential, protected and also guaranteed to be destined only to the legitimate person or device. Hence security and privacy requirements need to be set and applied to protect IoT.

Related works in this field considered the analysis of IoT's specific properties, to be able to analyze the security and privacy challenges, and this is the objective of this section.

A research study in HP [24] conducted on the security risks on the IoT devices, by viewing 10 of the most popular devices in some of the most common IoT architectures, shows that:

• 90% of devices collected at least one piece of personal information via the device, the cloud, or its mobile application such as name, address, data of birth, health information, and even credit card numbers.

• Six out of 10 devices that provide user interfaces raised security concerns and were vulnerable to a range of issues such as persistent XSS and weak credentials.

• 70% of devices do not encrypt communications to the Internet and local networks.

• 70% of devices along with their cloud and mobile application enable an attacker to identify valid user accounts through account enumeration.

• 80% of devices along with their cloud and mobile application components failed to require passwords of a sufficient complexity and length, hence weak passwords.

According to HP and OWASP those problems are mainly due to insufficient authentication and authorization, lack of transport encryption, insecure web interface and insecure software and firmware. Deeper analysis of those problems will be threatened in what follow. OWASP Internet of Things (IoT) Project,³ an Open Web Application Security Project explores and exposes the security risks associated with the IoT in order to help developers, manufacturers or any entity of interest to understand and make better decision when dealing with IoT technologies. This project is structured into sub-projects mainly the IoT attack surface area and the top IoT vulnerabilities.

The IoT attack surface ⁴ :

The IoT attack surface is pretty wide and exposes an exhaustive list of attacks surfaces and their correspondent vulnerabilities. In this section, we will go through the most important ones which will give us the essential background to continue the exploration of the advancements in the field of IoT security researches:

• Ecosystem Access Control: This area focuses on the problems related to control the access to the device, mainly the problems related to the implicit trust between the components, the enrollment security and the lost access procedures.

• Device Web Interface: it covers all the web attacks that the device's web interface may be exposed to such as SQL injection attacks, Cross-site scripting, username enumeration and weak passwords etc.

• Device Network Services: covering the network attacks that may threat the device, such as Denial of Service, poorly implemented encryption, unencrypted services, buffer overflow, relay attacks, etc.

• Local Data Storage: since the resources in the device need to be protected, several vulnerabilities may occur mainly in case of unencrypted data or data encrypted with discovered keys, lack of data integrity checks or the use of same static encryption/decryption keys.

• Mobile Application: vulnerabilities such as lack of transport encryption, lack of two-factors authentication, weak passwords, etc.

• Network Traffic: covers all the problems related to the communication protocols specially the wireless ones (WiFi, Zigbee, Bluetooth) and the application of fuzzing protocols to test the IoT applications.

• Authentication/Authorization: one of the most important problems, not only in the IoT but also in the WoT. The vulnerabilities are mainly related to the authentication/authorization related values (credentials, session keys, tokens, etc.), device to device authentication, device to mobile application authentication and the lack of dynamic authentication.

• Privacy: user data disclosure, user/device disclosure and differential privacy are the main vulnerabilities that an IoT user may be exposed to.

• Hardware (Sensors): and last but not least all the problems related to the electronic devices itself such as sensing environment manipulation, tampering and damaging the device physically.

Covering all the vulnerabilities provided by OWASP needs a lot of times. In the discussion that follows we will focus on the top ten vulnerabilities provided by OWASP. They are present in many attacks surface areas, and they form also the basis of the previous statistics made by HP.

IoT's top ten vulnerabilities ⁵ :

1. Insecure Web Interface: it's a threat that can be initiated either by an internal or an external attacker, exploiting the problems related to weak credentials or by the enumeration of users accounts. In term of exploitability and detectability, it is rated as EASY, which means that attacks of this type can be discovered just by manually examining the interface or by using automated testing tools. Also other issues can be identified using those tools such as cross-site scripting. The impact of an unsecured web interface may lead to data loss or corruption, denial of access and even complete device takeover. This is why it is rated as SEVERE regarding the impact.

2. Insufficient Authentication/Authorization: since access to the device's resource must be prohibited for unauthenticated or unauthorized entities, insufficient authentication or authorization mechanism is rated as SEVERE concerning the impact on the data and the device itself (data loss and corruption and even complete compromise of the device and/or the user accounts). The attacker can take advantage of the lack of granular access control and weak credentials, since authenticating entities with weak credentials may not be sufficient. In term of exploitability it is rated as AVERAGE and EASY in term of detectability.

3. Insecure Network Services: checking vulnerabilities related to open ports such as DoS, buffer overflow, and fuzzing attacks are very commune, since anyone who has access to the device via a network connection may attack the device, thus only the necessary ports need to be exposed and protected. Also, abnormal request traffic need to be blocked. Several DoS attacks have been proven to be efficient on the IoT devices [25,26] specially when unsecured network services are available, rendering the device unavailable or inaccessible to the user. In term of exploitability and detectability it is rated as AVERAGE. However, the impact is rated as MODERATE.

4. Lack of Transport Encryption: eavesdropping and tampering can be easily set by an attacker in case of unencrypted data sent over the network, since it is prevalent that the traffic in the local networks is assumed to be not widely visible hence the lack of transport encryption. However, traffic can be visible in case of a mis-configured local wireless network which may result in data leak or loss. Many propositions for end-to-end encryption using DTLS or a lightweight cryptography have seen the light [27]. In term of exploitability it is rated as AVERAGE and EASY in term of detectability. The impact is rated as SEVERE.

5. Privacy Concerns: protecting the user's private information is an important requirement in any system. In IoT case, the attacker can take advantage of a weak authentication, lack of transport encryption or unsecured network to gather personal non-protected information. This scenario can be crucial in case of confidential and sensitive information such as credit cards information or health information. Thus data anonymization, authorization and encryption need to be guaranteed in such environments. In term of exploitability it is rated as AVERAGE and EASY in term of detectability. As for the impact, it is rated as SEVERE.

6. Insecure Cloud Interface.

7. Insecure Mobile Interface.

8. Insufficient Security Configurability are also critical aspects that must be taken into account while dealing with such environment.⁴

9. Insecure Software/Firmware: even if the exploitability of this kind of vulnerabilities is DIFFICULT, its impact is considered as SEVERE, since it can lead to compromission of user's data and even to take control over the device. The device needs to be able to perform updates regularly, specially when vulnerabilities are discovered. The updates need also to be protected, since software/firmware updates files delivered on insecure network connection are susceptible to altering attacks. Consequently, encryption and integrity checks need to be performed. This vulnerability can be EASILY detected by inspecting the network traffic during the update and check the encryption.

10. Poor Physical Security: finally, physical attacks are widely used to access the operating system and the sensitive data stored in the device such as the encryption keys and the credentials, by disassembling it and accessing the storage medium. Precautions can be made by encrypting the stored data and ensuring that the USB ports can not be used maliciously. In term of exploitability and detectability it is rated as AVERAGE.

14.2.3.2 Security Requirements for the IoT

The exponential growth of the number of deployed devices and the size of data that will be exchanged on the network raised several challenges in order to achieve a global architecture. Those challenges concern not only the operational part, but also, and most importantly, the security and the privacy in such environment [28]. What makes the uniqueness of the IoT are the properties that need to be treated in order to define the security and the privacy challenges. Such properties, as explained in [29], are the result of the analysis of many related researches in the IoT field, they are mainly four properties: 1) Uncontrolled environment which is natural for an environment such as the Web especially when dealing with mobile Things (from one domain to another), physically accessible and requiring the establishment of trust relationships in order to exchange sensible information. 2) Heterogeneity since the IoT environment may integrate various types of entities coming from different origins. 3) Scalability related to the plethora of Things that need to be interconnected, hence a highly scalable protocols need to be applied and 4) Constrained resources in term of energy, computation capabilities and storage space. The same analysis shows that the security requirements can be grouped into five main sections: Network Security, Identity Management, Privacy, Trust, and Resilience.

Network Security:

Preventing eavesdropping, tampering, spoofing, denial of service, and so on, of sensitive information when they are sent via the Internet, either from a Thing to another or from a Thing to human, is an important requirement for network security. Confidentiality requires the establishment of a secure communication for the IoT's smart objects, specially when they communicate through the Internet. Traditionally, several technologies such as IPSec and TLS have been proven to fulfill the requirement, however they require significant cryptographic computations that exceed the capacities of the current IoT devices. Thus, dedicated secure network stack for the IoT needs to provide strong and lightweight encryption, so that the constrained devices can benefit from the same security functionalities that are typical of unconstrained domains. Most of the solutions trend to use a trusted unconstrained node to offload the computationally intensive tasks such as the calculation of the master session key. Another property guaranteed by the encryption is the Integrity of the data to ensure they are not altered during their way to the destination. While Authenticity provides proof that a connection is established with an authenticated entity, it can also include the integrity. And finally, the Things need always to be available meaning that the connectivity of a Thing should persist even under link failure, referring to the Availability property. Secure routing is also one of the issues that can occur in the network, and it can be instantiated through the implementation of secure routing with a strong protocol such as RPL [30].

Identity Management:

First of all, each object needs to be aware of its own resources such as identity, constraints, security requirement, etc. Due to the enormous number of devices deployed in the Internet, and the complex relationships that they can have with each other, appropriate identity management mechanisms need to be present. Still identity management alone is not sufficient showing the importance of authentication, authorization, accountability and revocation mechanisms. Authentication is very important to IoT and is likely to be the first operation carried out by a node when it joins a new network, which appears in first deployment or mobility cases as examples. Usually authentication is performed using an authentication server with a network access protocol such as PANA or Extensible Authentication Protocol (EAP) [16]. As for the management of the access authorization and the ownership of resources, federated authorization such as Kerberos and OAuth have the possibility to provide delegation of access across domains and provide quick revocation. A presentation of an authorization framework is presented in 14.2.3.3. As for the Accountability, it needs to deal with the massive amount of data that will be exchanged. Also mechanisms to manage the identity of the nodes and a key management with protocols such Authenticated Key Exchange (AKE) can be compatible with IoT [16].

Privacy:

Objects dealing directly with the private information of individuals and organizations raise a challenging privacy issue in IoT. The environment needs to provide data privacy for the data transmitted in the Internet, in the sense that traffic sniffed containing those data will not reveal/expose its content. For this reason mechanisms for data anonymity, pseudonimity and unlinkability need to be used to guarantee the privacy of the data in on hand and the entity itself (human or device) in the other hand.

Trust:

Giving a proper definition of the Trust specially in a distributed architecture such IoT is still a challenge, since any trusted entity can become malicious either intentionally or after being compromised. However, the Trust in this case can be separated into three parts. The first part is the Device Trust, since a prior trust cannot always be established due to the mobility and the distributions properties of IoT. However, approaches such as trusted computing [31] and computational trust [32] can solve the problem. The second part is the Entity Trust referring to the expected behavior of the different entities. This part presents more challenges. Solutions based on the behavior analysis and the application of proper policies need to be investigated. The last part is the Data Trust, which can use the previous established trust relationships to judge the trustworthiness of the data e.g., data originating from a trusted entity might be also trusted.

Resilience:

And finally the Resilience requirement, where the IoT applications need to ensure the availability of the resources in case of system failure, and also to have robustness against the different attacks.

14.2.3.3 Example of Security Model in IoT: OAuth-Based Authorization Service

Authorization as we defined it previously, is a critical aspect in accessing the objects in a secure way, and preventing unauthorized users form extracting information, in particular the private ones. Many innovative architectures have been proposed in the last years. One of the main problems related to the authorization process (for example with OAuth) is the limited computational power and the communication constraints of the smart objects, since some cryptographic primitives such as computing checksums or digital signatures require both processing power and energy consumption. Moreover, if the access policies for the services provided by the Smart Object reside on the Smart Object itself, it could be extremely hard to dynamically update them once they have been deployed. The proposed architecture, described below, solves this issue by deploying an external authorization service based on OAuth.

OAuth-Based Authorization Service for IoT (IoT-OAS), is a framework based on HTTP/CoAP services to provide an authorization framework, in order to protect the privacy of the personal information. This authorization is based on the protocol OAuth allowing a secure authorization form third-party applications, and benefiting from the advantages of using such delegated authorization protocol such as lower processing load, fine-grained customization of access policies and scalability. The proposed framework uses the access token in order to access the IoT application resources, and also a delegation approach [33].

Now that we have a global overview of the threats and the security requirements in the IoT, we will introduce the security of the WoT by listing the currently proposed models, mainly the identity management, data confidentiality and integrity, the authorization and the access control.

14.3.1.1 Identity Management Models

The general architecture of the identity management models in the WoT ecosystem is composed of an Identity Provider (IdP), a Service Provider (SP) and the user/object. In this section we will provide a brief sketch of the existing identity management models [39].

• Centralized federation model: where there is a unique trusted IdP responsible for collecting and provisioning users with identity information. Usually located in a secure domain, this model enables Single Sign On (SSO), and sharing the users identity information with different SP. However, the IdP suffers from the problem of single point of failure, if this part fails the entire identity management system will fail.

• Decentralized federation model: the IdP's functions are distributed among several IdPs, and in different secure domains. This model needs to establish a trust relationships between the SPs and the IdPs, in order to provide SSO to users affiliated to different IdPs and SPs. However in this model, the user does not have the full control of his identity information, since they are stored in the IdP, and they can be disclosed to a third party without his permission.

• User-centric model: this model solves the problem of controlling the user's identity, by providing the user with full control of all the transactions involving his identity. Concretely, the user needs to explicitly approve the use of his identity. The user/object can have one or more identities issued by one or more Identity Provider. Such system needs to guarantee several properties, some of the basic ones are the confidentiality, the integrity and the unlinkability. The complete taxonomy of properties related to the user control is illustrated in [39]. An example of user centric IdM is illustrated in [40].

14.3.1.2 Real-Life Identity Management Case Study: E-Health

A new E-Health approach combining remote medical assistance, with the use of smart objects in order to continually monitor patients suffering from chronicle illnesses or age-related diseases, can be brought by the WoT concepts. This kind of remote medical assistance is called Ambient Assisted Living (AAL). Some examples of smarts objects used in the health domain are peacemakers, remote vital signs and motor activity monitoring with wearable smart objects, and so on. They have direct and real-time access to the medical data of the patient. Communicating with those objects can be performed using two methods: directly, which needs powerful devices embedded with web servers or indirectly using a Smart Gateway that allows web interaction with different kinds of smart objects usually using different communication technologies [36]. The indirect method is the one used in this case study [41].

However, accessing private medical information by the objects raises serious security and privacy related problems. Generally in order to access health information by authorized people (relatives, professionals involved in the treatment), the patient's consent must be provided. Due to the high sensitivity of the information, these embedded devices needs to ensure privacy and security requirement, specially when they are directly exposed on the web. Thus authentication and access controls mechanisms needs to be deployed for this purpose. The use of an Authentication and Authorization Infrastructure (AAI) [42], can perfectly satisfy these requirements by providing the Identity Management to the platform together with guaranteeing the identification of the user/object and the quality of the identity information.

As we discussed above, several types of identity management can be deployed depending on the circumstances. In this case where the patient private information needs to be controlled by himself, the user-centric model is the most suitable choice, for authenticating users and devices and also for establishing a trust relationship between the different actors of the system, by adopting the OpenID Connect framework. It is a simple identity layer on top of OAuth2.0, providing identity verification of variant types of users, smart objects, applications, mobiles, etc., based on the authentication performed by the authorization server, or what we usually call IdP. It allows also to obtain a basic identity information about the requester in an interoperable and REST-like manner [43]. Furthermore some security requirements need to be provided by the WoT in addition to the identity management, such as secure exchanges between the entities, data confidentiality and integrity, secure network access just by the authorized objects and the protection of the objects against tampering and physical attacks.

The identity management in this case study helps to control the access to the medical information of the patient, in one hand by identifying the authorized users/devices, and in the other hand by countering the unauthorized people/devices through the use of OpenID Connect combined with policies based on the user-attribute located in the Smart Gateway [41].

14.3.2.1 End-to-End Security in CoAP's Transport-Layer

Several security-related issues are raised in [44], on how to allow secure communications on the WoT, either for Thing-to-Thing communication or for Human-to-Thing, since most of the applications currently envisioned for the WoT require strong security assurances while taking into consideration the constrained environment of the smart objects. Those issues need to be handled before it can realistically be considered ready for deployment.

For this objective, an experimental evaluation of the different mechanisms proposed to secure end-to-end web communications with IPv6-capable sensing applications and devices have been realized in [44]. Those experiments are based on the analysis of Constrained Application Protocol (CoAP) protocol [18] maintained by CoRE (Constrained RESTful Environments), by using the Representational State Transfer (RESTful) web services with IPv6-enabled sensing devices. In CoAP the security is not integrated at the application-layer protocol itself, but rather directly applied to all CoAP messages at the transport layer of the protocol. Thus deploying DTLS in protecting communications at the transport layer appears as a logical choice, since currently 6LoWPAN environments employ UDP, at least from the standardization's standpoint. CoAP proposes three security modes based on the usage of DTLS to secure web communications with smart objects: 1) RawPublicKey, 2) PreSharedKey, and 3) Certificates all employing the CoAPs scheme when contacting a DTLS-enabled CoAP server [18]. The RawPublicKey and Certificates modes employ Elliptic Curve Cryptography (ECC) by using the Elliptic Curve Digital Signature Algorithm (ECDSA) for devices and messages authentication, and the Elliptic Curve Diffie–Hellman (ECDH) for the key agreement. The PreSharedKey mode used in the case where the smart devices already store some predefined keys either provided by the manufacture or the developer or simply by the user. Those keys will be used to secure the communications with other devices.

The experiments done in [44] analyze the impact the different CoAP's security modes on the network-layer payload space, the memory footprint and the computation and the energy overhead of the smart devices deploying theses security modes.

From the first analysis on the overhead on network-layer payload space, they concluded that even if the impact of CoAP security on the payload space available to applications is visible (up to 33% of the payload), it may be considered viable for applications that are thrifty with respect to payload space requirements. However, fragmentation is unavoidable in case where the applications requires a larger payload.

From the second analysis on the memory footprint of CoAP security, they concluded also that hardware-level encryption does not come without a non-negligible overhead on memory, especially the ROM memory (in the best case 78.9% will be needed in the Certificate mode). They also identified a major limitation that there is not enough ROM memory available to support the RawPublicKey mode. RAM is potentially a problem in this case, since 88.6% of memory usage in case of RawPublicKey mode may compromise the usage of other required applications in the device. Elaborated sensing devices with more memory will be required in the future to appropriately support ECC-based security modes. The remaining CoAP security modes appear to be valid in this case.

The last analysis concerns the computational and energy overhead of CoAP security, the outcome is that a significant impact of ECC on the performance and energy of current sensing platforms, inevitably influences the lifetime of sensing applications and its maximum achievable transmission rate. The advantage of hardware-based cryptography is again expressed by the values obtained from the PreSharedKey mode, therefore a good choice when pre-deployment and configuration of security-related parameters on sensing devices is desired. For scenarios where public-key cryptography is required, the Certificate mode appears again the best alternative to ECC.

The analysis concluded that the modes deploying the Elliptic Curve Cryptography consume more memory and energy, and cannot be used for high transmission rate. However in the future the ECC approach can become very promising with the evolution of the capacities of the smart devices due to the strong cryptographic properties proposed.

14.3.2.2 End-to-End Security in CoAP Application-Layer

Indeed, application-based security have been proved to have the capability of interpreting and interacting directly with the information contained in the payload portion of a datagram such as the application proxies used in most firewalls for FTP transfers. These proxies have the ability to control and restrict the use of certain commands even if they are contained within the payload part of the package. Moreover, lower-layer security protocols like DTLS do not have this capability. They can encrypt the commands for confidentiality and authentication, but they cannot apply restriction and policies for their use.

Hence, deploying such security in the transport layer in CoAP misses all the advantages available in the usage of security at the application layer. Another analysis, done in [45], focusing this time on the security of the end-to-end communications between devices at the application-layer rather than the transport layer of the protocol. Respecting the limitation brought by the WoT applications, this mechanism is employable in the context of a general security architecture supporting web-enabled sensors (Things).

Historically, several approaches were proposed to address in particular the end-to-end communications security between 6LoWPAN wireless sensing devices and Internet hosts. However, most of them are not compatible with the current vision of WoT using CoAP and 6LoWPAN as standards. We mention Sizzle [46] which is one of the smallest web server providing HTTP accesses secured using SSL's 160-bit ECC keys, for key negotiation and authentication, but requiring a reliable transport-layer protocol and therefore was incompatible with CoAP and 6LoWPAN at that time. However since then researches have evolved enough so that CoAP can now provide reliable transmission of messages according to the RFC7252 (Section 4.2 in [18]), by adding the Confirmable option to the CoAP's header. This would be a possibility to a future analysis of using Sizzle with the current CoAP. However, another issue with Sizzle is that it does not support two-way authentication which is required by many Machine-to-Machine (M2M) applications on the WoT environment. As an alternative, Sensor Networks for All-IP world (SNAIL) [47] secured using a lightweight SSL (SSNAIL) is another solution proposed to solve the two-way authentication using an ECC-enabled handshake instead of RSA [48], also requiring a reliable transport-layer protocol that was not available at that moment. This reliability can also be brought by CoAP, thus extra analysis can be done to check the compatibility of SNAIL in the WoT environment. More in line with the security in the application layer, a proposed solution for the integration of security with CoAP using options for the activation/deactivation of security contexts and for the protection of CoAP messages have been proposed and abandoned in an IETF draft [49].

The proposed mechanisms integrate and evaluate the security at the application-layer with the CoAP, by adding new security options to CoAP. The first option is SecurityOn which precises if the received CoAP message is protected with an application-layer security or not. This option states which security is applied (encrypted, signed or both) in the SecurityApplied field; the Destination Entity identifies the actor CoAP URI that the destination must handle, this option can be employed several times in the same CoAP messages to enable the traversal of different trust domains and possibly using different encryption keys; the timestamp to verify the legitimacy of the message; and finally the Context identifier enabling the receiver to contextualize the message in term of security, in particular deciding the appropriate ciphers and keys.

The second option is the SecurityToken enabling the use of authorization and identity mechanisms. With this option, the requester may identify itself to obtain the access to a given CoAP resource. This option enables also request authorization based on a per message basis. Using the “TokenType” field, the requester can precise the authentication mechanism, that can be either a simple authentication process using its Username and Password or with a more sophisticated authentication process using its public-key, its X.509 certificate referred by a URI, or a kerberos ticket obtained from a domain server.

The last one is the SecurityEncap option. It transports the security related information required for the processing of the CoAP message, which depends on the content of the SecurityOn option. If only an encryption is required in the SecurityOn message (SecurityApplied set to 0), this message may transport a nonce plus the number of options followed by the encrypted data. If the SecurityOn requires a signature (SecurityApplied set to 1) this message may be used to transport an encrypted MAC plus a nonce value for freshness purpose. If the SecurityOn message requires both encryption and signature (SecurityApplied set to 2) a nonce, a MAC, a number of options and encrypted data may be transported with this option. More details on these new CoAP's security options can be found in [45].

An evaluation of the deployment of these options have been achieved to evaluate the impact the end-to-end security on the CoAP payload, the lifetime and the communication rate of the sensing application. The test platform is composed of a CoAP sensor (TelosB), an Internet host using CoAP and a CoAP intermediary (a forward proxy) that will be used for security processing. Via the SecurityToken option, the intermediary will provide authorization of CoAP clients and access control to the resource. As explained in Fig. 14.2.

The first evaluation is the impact of end-to-end security on the payload space of a CoAP packet, it computes the space needed to add security in the application layer. The analysis shows that the usage of the CoAP security intermediary in the encryption and the signature performs even better than using only CoAP with DTLS in the transport-layer. Thus the usage of the intermediary allows offloading the security computation, and guaranteeing a very small impact on CoAP's payload space. The analysis also shows that in the worst case when using encryption, signature and authentication, 65% of the original 6LoWPAN payload is still available. Hence, this approach is viable from the payload space point of view.

The second evaluation is on the lifetime of sensing application, by computing the energy consumption of the device when using such security options. It shows that the usage of the CoAP security intermediary in the encryption and the signature perform even better than using only CoAP with DTLS in the transport-layer. However, end-to-end CoAP security without an intermediary has bigger impact on the expected lifetime, specially for lower communication rates where the cumulative impact of AES/CCM encryption in the default CoAP security context is lower compared to the impact of the energy required to process and transmit CoAP security options. Consequently the obtained results show that CoAP security provides acceptable lifetime values in all usage scenarios, particularly considering the WoT applications natively designed to require low or moderate wireless communications rates.

Finally concerning the impact of end-to-end encryption on the communication rate of sensing applications, the study shows that using CoAP signing and encryption of all messages (as using DTLS) provides inferior performance. However, the results are still clearly above the requirements for the number of CoAP protected messages per second of most CoAP wireless sensing applications envisioned for the WoT, even in the worst case.

The overall evaluation of the proposed mechanism shows that CoAP application-layer security may perform similarly or better than transport-layer security. This approach brings new security to CoAP messages that are not possible in the transport layer to allow secure end-to-end communication for WoT wireless sensing applications, but still needs further investigation specially in term of key management and synchronization mechanisms [45].

14.3.3.1 Authorization Framework Example 1

An implementation of the previous architecture was proposed in [52]. It's a protocol for delegating the heavy security tasks such as authentication and authorization information to a less constrained and trusted entity. It relies on the DTLS to send authorization information and shared secrets (basically symmetric cryptographic keys) between nodes in a constrained network. It uses the notion of access token to implement the authorization architecture for constrained environment such as WoT. This protocol is called DCAF [52].

The goal of DCAF is mainly to setup a secure DTLS channel between two constrained nodes using the symmetric pre-shared key (PSK) cryptography, where the most sophisticated tasks are handled by the less constrained nodes. Moreover, DCAF ensures secure transmission of authorization tickets and enforces the authorization policies defined by the respective principal of the constrained node. Another advantage of the protocol is the support of implicit authorization where no authorization information are exchanged, hence a simplified authorization mechanism.

The actors of this implementation remain the same, with a difference in the terminology:

• Server (S) referring to the “Resource Server (RS)”.

• Client (C) remains the same.

• Server Authorization Manager (SAM) referring to the “Authorization Server (AS)”.

• Client Authorization Manager (CAM) referring to the “Client Authorization Server (CAS)”.

• Authorization Manager (AM) which can be either a SAM or a CAM.

• Client Overseeing Principal (COP) referring to the “Requesting Party (RqP)”.

• Resource Overseeing Principal (ROP) referring to the “Resource Owner (RO)”.

Fig. 14.4 is a global overview of the proposed architecture, it summarizes the main interactions.

As explained before in the authorization architecture, each server (S) (which is a constrained environment that hosts a resource and it can be a Thing) is controlled by a Server Authorization Manager (SAM) that will perform the authorization and authentication process on its behalf. They both have already a pre-shared symmetric key that was exchanged initially using a key exchange mechanism.

When a client requests an access to the server's resources, he/she has first to ask the SAM for an “Access Ticket”. The client can be either a constrained device (a Thing) or a less constrained device. In the case of a less constrained client, he/she can directly request the access ticket from the SAM, that will perform the “Check 2” to verify if the client is authorized to access the server's resource, by consulting the Resource Overseeing Principle (ROP) policies. Once the check is done correctly, the client will get an access ticket that contains a PSK, and also some details for the access permission in case of explicit authorization. Using this PSK, the client can directly and securely communicate with the server.

In the second case where the client is a constrained device, in order to get the access ticket he/she needs to go through a CAM that will act on his behalf, represented as step 1. The CAM will perform “Check 1” to verify if the server is an authorized source for the wanted resource, by consulting the policies defined by the COP, and then will forward the request to SAM (the step 2). Similarly, SAM will perform the “Check 2” to verify if the client is authorized to access the server's resource, by consulting ROP's policies. Once the check is done correctly, it will return an access ticket that contains a PSK and also some details for the access permission in case of explicit authorization which is represented by the step 3. Another check is done by CAM to verify if the permission in the access ticket complies with COP's authorization policies for the client (“Check 3”), then sends the ticket to the client which is shown in step 4. Finally, the client can use the PSK to directly and securely communicate with the server in step 5.

Some requirement has to be fulfilled by the authorization manager (SAM and CAM) in order to be able to provide the authorization and the authentication services. Mainly, they need to have enough storage space to store the different credentials, to be able to directly interact with the user, for example, through an interface, and of course have enough processing power to handle in one hand the different authorization requests, and in the other hand to be able to efficiently generate the PSK for a given client.

For security purposes, the channels between CAM and the Client, the channel between SAM and Server and the channel between CAM and SAM are encrypted by DTLS using the pre-shared keys. Also an authentication must be done between SAM and CAM to determine if the request is authorized or not. In this case, CoAP is used to interchange access-related data between the server and SAM in order to provide the server and the client with enough information to establish a secure channel. More details on the messages exchanged and the Ticket are presented in [52].

14.3.3.2 Authorization Framework Example 2

The second authorization framework complements IoT-OAS, an authorization service architecture based on OAuth for secure services in IoT scenarios [33] as we explained in 14.2.3.3, by introducing access token mechanism to access the IoT resources. The analysis is also based on the delegation approach to authorization introduced by IoT-OAS, which can also manage fine-grained access to web resources in the WoT.

The proposed system is composed of four parts: the smart objects, the owner, the external user who wants to access the object and the delegation authorization service IoT-OAS. A preliminary process is the authentication of users into IoT-OAS using one of the known authentication mechanisms (Google login, Tweeter login, Facebook login, etc.), once logged the user will be granted an access token to authorize him to interact with IoT-OAS.

The permission hence will be expressed by the tuple $<\mathit{res},\mathit{act},\mathit{exp}>$ where res is the URI of the object, act is the REST method that will be sent to the object and exp is the expiration time. The full method and messages are expressed in [55].

In fact owners prefer not only to restrict access to their object's resources, but also want to be able to grant access to authorized parties. In this case we distinguish two possible access policies:

1. Owner-to-Owner authorization: where the owner explicitly gives permission to himself to access or control an object. This type of authorization can be addressed using the OAuth 2.0 protocol [50]. The owner reads the UUID of the object, and sends a register request to IoT-OAS, which verifies if the object belongs to someone else, if not, will bind the object to the owner and grant him an all-access token allowing him to execute any operation on the object. The full message flow is explained in Fig. 3.a of [55].

2. Owner-to-Any authorization: where the owner can grant authorization to access one of his/her objects to other parties. This type of authorization in the web can also be addressed by the OAuth 2.0 protocol using the User-Managed Access (UMA) profile. This type of authorization can be either Reactive, where the external user asks the owner for permission, as explained in Fig. 3.b of [55], or Proactive where the owner gives directly the authorization to the external user, as explained in Fig. 3.c of [55].

14.3.4.1 Example 1: Access Control Through Resource-Oriented Architecture of the WoT

A decentralized access permission control using resource-oriented architecture for the WoT has been proposed in [62]. It adopt the REST-style to allow Things and users to manage access privileges to their own web resources, which are accessible through a unique URI. They propose 5 steps to control and assure any resource access request coming from an external user. Those requests must be transported via a secure channel. As it is explained is the same paper, the first step to control the access to the resource is by filtering TCP/IP packets, especially filtering out the unallowable domain access. The second step is to parse the HTTP/REST request by filtering out the invalid requests and the abnormal parameters. The third step is to checks the HTTP header for basic authentication purpose so that the unverified users will be blocked. The fourth step is to check whether the requested resource exists or not, since requests for expired or irrelevant resource must be automatically dropped. And finally, the system needs to check the assigned access permission for the request operation. Unassigned access permission for a requested operation must be filtered.

The study focuses on the CRUD operations that can be applied on the object's resources, where a specific permission policy can be applied to each REST request. This permission policy, expressed using XML, can contain the requester information such as IP address, domain, host name, etc, and also some contextual information about the object itself, such as the time duration, localization, hardware state, capabilities, etc. An example of access rights for each CRUD operation to an object is shown in (14.1):

$\begin{array}{cc}\hfill & \mathit{Permission}\mathrm{\_}\mathit{Flag}\mathrm{\_}C[/R/U/D]=\{X\}\cap \{Y\}\text{[62]}\hfill \\ \hfill & X=\mathit{Condition}\mathrm{\_}\mathit{about}\mathrm{\_}\mathit{subjects}\hfill \\ \hfill & Y=\mathit{Condition}\mathrm{\_}\mathit{about}\mathrm{\_}\mathit{the}\mathrm{\_}\mathit{requested}\mathrm{\_}\mathit{object}\hfill \end{array}$

Handling the rules that have more than one condition has to be settled by the implementation. Assuming that all the conditions have the same priority to grant permission. There are two cases, either all the conditions need to be met or at least one of them. A more precise representation can be applied by dividing the condition part into two categories: inclusive and exclusive. In this paper the chosen rule was: “Permission is granted if any of inclusive conditions meets when any of exclusive condition does not meet” [62]. Then, the expression can be represented as shown in (14.2):

$\begin{array}{cc}\hfill & \mathit{Permission}\mathrm{\_}\mathit{Flag}\mathrm{\_}C[/R/U/D]=\{X\}-\{Y\}\text{[62]}\hfill \\ \hfill & X=\mathit{Union}\mathrm{\_}\mathit{of}\mathrm{\_}\mathit{inclusive}\mathrm{\_}\mathit{conditions}\hfill \\ \hfill & Y=\mathit{Union}\mathrm{\_}\mathit{of}\mathrm{\_}\mathit{exclusive}\mathrm{\_}\mathit{conditions}\hfill \end{array}$

14.3.4.2 Example 2: Role-Based Access Control

Another example of access control is presented in [63], introducing the use of the RBAC [58]. It specifies the access policies for the plethora of data published by Things in the Web, and also how to access them and how the access can continue or should terminate. Cryptographic keys are also deployed to enforce those policies. The benefits from using RBAC reside in supporting a set of important security properties such as data abstraction, least privilege and the simplicity of adding access rights to users as long as the existing roles are used.

Generally each User is assigned a Role and each role is assigned to a Permission, hence users acquire permission to access a particular data depending on theirs roles. The user can have many roles and a role can be assigned to many users, same for the role which can have many permission, a permission can be assigned to different roles. And finally, each assignation needs to take into account the different constraints, for example to enforce conflict of interest policies that Thing's owner may employ to limit the number of users able to access Thing's resources. A more elaborated analysis can be found in [64].

However, RBAC suffers from the role proliferation problem related to the issues of dealing with a large amount of data, for instance granting permission to a big number of users to access a Thing's dataset, where each permission depends on the user's affiliation to the system. More precisely, the problem lies in handling the task of assigning a single role to each user which can be complicated in this case. Role parameterization have been proved to be an efficient solution in these types of scenarios [65]. The global proposed RBAC/WoT architecture, as explained in the paper, can be summarized in Fig. 14.7.

The proposed security architecture in Fig. 14.7 aims at integrating RBAC model into a WoT-based environment by mapping the RBAC entities with the WoT entities. Where the Things in WoT are represented as users in the RBAC model, with a set of permission that will grant privileges to the users and eventually the Objects. Also a set of RBAC authorization rules needs to be respected in order to access any WoT entity (user/object). The access control of the object's resources is done centrally. To enforce the specified access policies in WoT, RBAC needs to use the concept of reference monitor (RM), a process continuously running inside a trusted computer base, referring to the core control mechanism for the access and the usage of digital information. The reference monitor, located in the ambient space manager, is composed of two main components 1) the Access Control Enforcement Facility (AEF), located in the Monitors section and the 2) Access Decision Facility (ADF), located in the Rules Engine section. The two components interact with each other in order to approve or block an access request. Mainly, the AEF intercepts the different requests, and asks the ADF for a decision. The decision is then enforced in the AEF. More details can be found in the RM standard and [63].