VII. Security of IoT Protocols
Hence, new standards are being developed with lightweight security designs. In addition, there exist a few IoT standards specializing in providing security as shown earlier in Fig. 2. In this section, we discuss several of these security standards, drafts and research works. We refer the reader to  for more details on IoT security standards.
A. Security within IoT Protocol Layers
Protocols such as 802.15.4e, WirelessHART, 6LoWPAN and RPL offer some security features to secure the communication in their respective layers.
MAC 802.15.4e offers different security modes by utilizing the “security enabled bit” in the frame control field in the header. Security requirements include confidentiality, authentication, integrity, access control mechanisms and secured time-synchronized communications.
Thus, it provides different levels of security, depending on the application, using latest employed techniques.
A few IETF documents that are relevant to 6LoWPAN discuss security threats and requirements of 6LoWPAN and propose solutions. For example, RFC 4944 discusses the possibility of duplicate EUI-64 interface addresses which are supposed to be unique . RFC 6282 discusses security issues that are raised due to the problems introduced in RFC 4944 . RFC 6568 addresses possible mechanisms to adopt security within constrained wireless sensor devices . In addition, a few recent drafts  discuss mechanisms to achieve security in 6loWPAN. See also , .
RPL offers different security levels using the “Security” field in its header. Information in this field indicates the level of security and the cryptography algorithm used to encrypt the message. RPL offers support for data authenticity, semantic security, protection against replay attacks, confidentiality and key management. Levels of security in RPL include: unsecured, preinstalled, and authenticated. RPL threats include selective forwarding, sinkhole, Sybil, hello flooding, wormhole and Denial of Service attacks. RFC 7416  discusses security threats and possible attacks to RPL, including confidentiality, availability and integrity attacks with their possible countermeasures.
TLS provides the security services over TCP transmission while DTLS provide such services over UDP or datagram transmission. TLS and DTLS are composed of two sublayers of protocols – record and the handshaking – which are responsible for the encapsulation and authentication, respectively. RFC 7925 discusses the detailed mechanisms used in these standards to provide security and privacy . These standards can provide credentials, signature, error handling using traditional security mechanisms, but modified to fit resource constrained devices used in IoT.
C. Ubiquitous Green Community Control Network Security
These networks provide high quality, energy saving and secure mechanisms that are suitable for IoT. Security requirements include information protection, integrity, confidentiality, authentication and access control. The standard provides recommended architectures and components that are needed to achieve security in such system. More importantly, the standard specifies communication sequence and security mechanisms that can be used, including: handshaking, authentication and access control mechanisms .
The mechanisms include authentication using unique identifiers, protection against middleware infections using TLS, and proven availability, confidentiality and integrity using various techniques. The techniques include the root of trust for update (RTU) and trusted platform module (TPM) which are used in TCG compatible devices . Specifications can help IoT developers to pick mechanisms that secure their applications, however, it is up to the developer to balance system security with complexity and resource needs.
E. OAuth 2.0
Such server would check client credentials and access rights and decide on the permission based on such information. Messages in this framework are based on HTTP which is rarely used for IoT due to its overhead compared to others . RFC 6819  describes additional security considerations that extend OAuth to include new threat models and solutions. The authors in  discuss threats and open security issues that go beyond OAuth 2.0 and need to be solved in future versions of this protocol. These threats include credential leakage, injections, and risks in the third-party authorization server.
It decouples the application from authentication process and uses simple messages to authenticate clients using application specific authentication mechanisms. Typically, in IoT, this framework is supported by session layer protocols that support TLS and SSL, such as, MQTT and AMQP .
It is conceptually like OAuth. However, it is built on CoAP based messages which is more suitable for IoT. It should be noted that the specifications have recently been approved in IETF RFC 7744 , and another draft  is in progress.
H. Recent IETF drafts on IoT security
Despite the large amount of security protocols and standards that have been proposed for IoT, threats and malicious behaviors are still challenges requiring further research. Some of these challenges and security requirements are discussed in several recent IETF drafts which we summarize next.
The authors in  summarize many technical and non-technical challenges in IoT security. Such challenges were gathered from enterprises offering IoT platforms and, hence, they are practical challenges rather than research challenges. Security and privacy of data are considered as the biggest challenges faced in the current IoT implementations and, hence, lightweight solutions for these challenges are yet to be developed.
Further, another draft  discusses the current practices for securing IoT devices from the network perspectives. The discussion includes requirements for IoT security, the use of security protocols to provide such requirements and the challenges faced in using such protocols. In addition, the authors provide recommendations for security solutions and implementation guidelines that are helpful for IoT enterprises. Hence, this document can serve as a guideline for IoT security minimum requirements and the current security issues to be solved in further research.
I. Other work done on IoT security
In line with all the standardization work discussed in this section, a lot of research papers and surveys have been published but not yet standardized. We briefly discuss some of these in this subsection.
New protocols to provide security are discussed in [, , ]. A lightweight end-to-end key mechanism for resource constraint devices used in IoT is proposed in . This protocol is based on offloading the computationally complex cryptographic operations to a trusted non-resource constrained neighbor device or node that provides strong encryption and authentication features. However, requiring a trusted third party which does all the work defeats the privacy constraint. An architectural design was proposed in  to meet the security and privacy requirements during the lifecycle of an IoT device. This architecture is based on an architectural reference model (ARM) which is designed by IoT-A European project for broader interoperability among IoT systems. The paper describes the instantiation, implementation, deployment, and testing of this architecture in IoT platforms. In addition, a monitoring solution for 6LoWPAN-based sensors that enables data capture, event extraction, statistics collection, analysis and reporting of wireless sensors behaviors is described in . Having such reporting of the sensors would result in better intrusion detection and deep inspection on the network traffic.
Surveys of standardized and non-standardized IoT protocols are presented in [, , ]. The first survey provides an extensive analysis of IoT security protocols and mechanisms in addition to open research issues and challenges faced in this field . Security challenges faced by industries offering IoT platforms are discussed in . The discussion includes challenges in using the protocols discussed in the paper. Specifically, the authors focused on different security mechanisms for key generation and analyzed the effect of using those mechanisms on MQTT. Finally, several state of the art mechanisms are discussed in ,  to provide cryptographic solutions, vulnerabilities detection and intrusion identification in IoT platforms.
J. Blockchains for IoT security
Blockchain is the distributed ledger technology that provides security by design without referring to a centralized or trusted third party authority . It is traditionally used in Bitcoins, and other virtual cryptocurrency platforms, but recently been investigated in many other domains including IoT. IBM and other IoT enterprises are considering providing Blockchain solutions for IoT security . Blockchains can be also used to provide privacy provisioning in IoT platforms  In , the authors discussed mechanisms to share data between IoT devices and organizations in a secured way using blockchains. In addition, building smart contracts using blockchain technology has been discussed in . Furthermore,  provided a survey of blockchain based architectures built for IoT platforms.
Several IETF standards have been proposed to offer security for such platforms including ACE, TLS/DTLS and many others discussed in this section. In addition, we presented some of the recent drafts discussing the challenges and threats to IoT security. It should be noted that IETF has a specialized group, called DTLS in constrained environments (DICE), for IoT security and is applying DTLS to all IoT applications. Furthermore, several recent research in providing IoT solutions have been discussed in this section.