IPv6 in a Nutshell

I’ve seen dozens of articles on this subject over the past few years while doing research for various projects, so I have become pretty familiar with the subject of IPv4 and IPv6. That being said, I have read numerous articles that were pages upon pages long, which ended up summarizing to the same few points to answer the question of “what is IPv6?” Rather than write a ridiculously long article on the subject, how about the Cliff Notes version?

What is IPv6?

IPv6 is an acronym for Internet Protocol Version 6, and is the successor to IPv4. That being said, IPv6 is also referred to ad IPng (Internet Protocol Next Generation). The Internet Protocol is a packet-switching networking protocol created by the Internet Engineering Task Force (IETF) that is used to assign addresses to devices connected to a network, so other devices will know how to find them. This address serves the exact same purpose as a postal mailing address; it allows someone to send letters (or datagrams in this case) from point A to point B. IPv6 was primarily created to address an issue with IPv4, in which the world just happened to run out of assignable IP addresses!

How is IPv6 Different from IPv4?

IPv6 addresses the IPv4 address shortage by changing the length of addresses from 32 bits to 128 bits, effectively adding an additional 2^96 addresses (about 7.9 octillion, for a total of nearly 3.4 undecillion allowable addresses; 3.4*10^38). That’s quite a gain compared to the 4.3 billion that IPv4 allowed for. While they were at it, the IETF also bolstered security (or at least planned for it), simplified the packet header format, added better support for multicast and Quality of Service (QoS) routing, and added support for an auto-configuration mode, which will allow devices to create their own address without user intervention. These changes have also allowed the concept of NAT (Network Address Translation) to no longer be needed. This is very handy when it comes to Internet of Things (IoT) connected and mobile devices!

Will my older devices still work with IPv6?

Well, yes and no. IPv6 and IPv4 can run in a dual-stack environment, meaning that your old devices will continue to work, and will be able to communicate with IPv6 devices (using many other protocols that allow the gaps to be bridged). Some of your devices probably already support IPv6. Should you know if they support it? Not unless your a Network Admin or Software Developer. If not, then do your devices still work? If so, don’t worry about it. If not, replace them; the replacement devices will, most likely, support IPv6.

Like this article? Feed the Developer: 

The Internet of Things Needs Security!

It has been over a year since I wrote an article about the Internet of Things, and the technology around it has evolved considerably since then. In the year since my last writing on the subject, extensive trial and error testing on my part has revealed a few pitfalls with utilizing the Constrained Application Protocol (CoAP) with a Datagram Transport Layer Security (DTLS) connection:

  • DTLS and CoAP were designed to operate at Layers 2 and 3, respectively, but very few considerations were made for them to inter-operate without marshaling data between the two layers.
  • DTLS is a connection-less protocol, CoAP is connection/session-oriented, forcing the developer to either sustain DTLS connections (insecure), or use CoAP without sessions (bandwidth-intensive).
  • Because the use of two distinct protocols is required, development complexity increases. A developer would need to write software to bridge the two protocols, handle key/certificate creation and management, and device provisioning schemes, taking away for development efforts that could be put towards building the IoT device itself.

Overall, the CoAP over DTLS concept was very elegant, but exceptionally complex and cumbersome for mass use outside of applications that require a high level of security (such as electric/water/gas utility use), and CoAP alone was very insecure, but provided everything you would ever need for communicating with embedded IoT devices, specifically sensors. To be more specific, the CoAP protocol on it’s own was very well designed (utilizing a RESTful design which allows it to operate much like HTTP), but highly-tailored for interacting with sensor devices for reading data. While provisions were made for writing data to devices to control their sensors, this can be a dangerous thing to do when your communications are unsecured.

For the Internet of Things to truly catch on for global use, a new protocol needs to be developed that takes all of the best parts of CoAP, and expands on them to add native support for security. Until an open standard can be developed that will all devices to be secured out-of-the-box, the Internet of Things will be nothing more than a novel concept in a niche market, where there is always the fear that your device will be compromised (an excellent example of this is a case where a web-connected baby monitor was hacked in 2012, allowing the hacker to scream obscenities at a sleeping toddler. Nice work Foscam…)

As long as a new protocol is being defined and developed, the following points should be considered. The protocol should:

  • Remain lightweight, and be inherently secure by default, with the option to disable security of needed for some reason (why? I couldn’t tell you)
    • The protocol should be secured using quality encryption, but be simple to use. “Secure by encryption, not obfuscation”.
    • To remain lightweight, the protocol must be binary. Humans do not need to be able to “read” the protocol in its raw form. Plain text protocols are dead, get over it.
  • Operate at Layers 3 and above, but should fully encompass the operations of all layers in a single protocol package
    • The protocol should be flexible enough to operate over UDP, TCP, BLE, and any other layer 2 protocol without modification, and simple enough to operate over any layer 1 medium
  • Follow a RESTful architecture, supporting CRUD operations
  • Support connection-oriented and connection-less communications
  • Support commands that require responses (confirmed commands), as well as commands that do not require a response (unconfirmed commands)
  • Support both unicast and multicast communications
    • The protocol should be capable of communicating over a traditional client-server network, as well as peer-to-peer networks, such as Tor
  • Be generic enough to allow transmission of any type of data, but flexible enough to be tailored for sensor/device-related operations
  • Utilize TLV structures for encapsulating all data being transmitted in the payload
  • Utilize simple and short URIs for data I/O operations
  • Be Free and Open Source, unencumbered by patents and proprietary lockdowns which would limit growth of the protocol and IoT utilizing it

If these basic considerations are taken into consideration while the protocol is being defined, the Internet of Things could greatly benefit from the work, and finally have a common and secure base from which to start to grow. Without the development of a protocol that follows these guidelines, I fear that the Internet of Things will eventually grow into a mass of millions (or billions) of unsecured devices, all running their own proprietary protocols which are built on top of an already over-layered Internet architecture.

Like this article? Feed the developer, every dollar counts: 

Securing the Internet of Things Using the Data Transport Layer Security Protocol

Introduction

The Internet of Things is a concept that has evolved over decades to define how billions of devices (or “Things”) are and will eventually be networked together to share data in real time. Devices will communicate with each other to exchange information about anything, and will utilize the latest technologies to create an ever-growing network that can be used for anything. As networks grow and data becomes more sensitive, it becomes important to discuss and define means for securing the data that is transmitted throughout the Internet of Things, and the devices that are a part of the networks. The purpose of this document is to discuss the technologies that are currently being utilized with the Internet of Things, and define mechanisms that can be used to enhance device and data security, as well as user privacy.

What is the Internet of Things?

“The Internet of Things (IoT) is the network of physical objects or “things” embedded with electronics, software, sensors, and connectivity to enable objects to exchange data with the manufacturer, operator and/or other connected devices based on the infrastructure of International Telecommunication Union’s Global Standards Initiative. The Internet of Things allows objects to be sensed and controlled remotely across existing network infrastructure, creating opportunities for more direct integration between the physical world and computer-based systems, and resulting in improved efficiency, accuracy and economic benefit. Each thing is uniquely identifiable through its embedded computing system but is able to interoperate within the existing Internet infrastructure.” [1]

Current Security Concerns

While the term “Internet of Things” has been used for over twenty years (attributed to Kevin Ashton in 1999), and software and hardware developments have begun to make the IoT a reality, little consideration has been put into how to implement security features in IoT-capable devices. In past years, several experts have theorized about various security concerns and privacy issues that would arise by an implementation of the internet of things. These concerns primarily fall under two categories:

  • User privacy – Users having the ability to consent to allowing their Things to be a part of the IoT, and having the ability to easily join or leave the IoT, while remaining anonymous, such that the data their Things generates cannot be used to identify any individual entity, while still remaining useful.
  • Data security – Data, software, and hardware being secured in such a way that the data being transmitted throughout the IoT cannot be utilized in a malicious manner, either for gaining control of remote software applications/hardware components, or for spying on unsuspecting individuals.

The Constrained Application Protocol (CoAP)

In current developments of the Internet of Things, the Constrained Application Protocol is becoming widely used for facilitating the network connections between “things” for Machine to Machine (M2M) communications, though there is no de-facto standard for network protocols to be used at this time. The Constrained Application Protocol (CoAP) is a simple application layer protocol that has been designed specifically for use on small embedded devices, where CPU, memory, and power resources are limited (or “constrained”). CoAP is modeled after the HTTP protocol which has been slimmed down and converted to a binary form to reduce network bandwidth utilization, while providing new features such as multicast support.

While CoAP has become a candidate for being used as the de-facto standard for IoT communications, it is designed specifically for facilitating inter-device communications, and does not attempt to address any security concerns, leaving the topic of security up to another software protocol to define. Recently, attempts at utilizing existing security technologies to secure CoAP have been made, which have been based around the use of either pre-shared key or certificate-based technologies, such as SSL/TLS. Due to the size and physical requirements of implementing a full SSL/TLS stack that would work effectively and efficiently in a constrained environment, a new protocol has been developed called Datagram Transport Layer Security (DTLS), which has been recommended for use as the security protocol of choice for securing CoAP network traffic, along with guidelines for implementing DTLS-secured CoAP sessions.

The Datagram Transport Layer Security Protocol (DTLS)

In the same sense that CoAP is modeled after HTTP, the Datagram Transport Layer Security (DTLS) protocol has been modeled after the Transport Layer Security (TLS) protocol, implementing all of the necessary security features of TLS in a more compact manner, allowing DTLS-capable devices to support both pre-shared key and certificate-based security technologies in a constrained environment. DTLS is designed to operate at network layers 2 and 3, and is responsible for encrypting all data sent and received over a datagram based network.

DTLS Using Pre-Shared Key (PSK)

The DTLS protocol in its simplest state can be used to secure network traffic by encrypting it using Pre-Shared Keys (PSKs). These pre-shared keys are generally installed on both the client and server devices during manufacturing (or using an out-of-band mechanism after device deployment), and are used during the DTLS handshake process to negotiate a common key (by combining the pre-shared key with random values supplied by the client and server applications) that will be used by both devices for encrypting and decrypting data.

While this is a quick way for two devices to secure their network communications, this method is somewhat lacking, in the sense that the devices are not authenticated in any way. While this does secure network traffic between two devices, it does not allow the devices to have any awareness of each other, which requires an out-of-band mechanism for handling Machine to Machine (M2M) authentication and access control.

The use of PSKs can also be somewhat insecure. If PSKs are installed on devices during manufacturing, they can usually be recovered by gaining access to the device; similarly, an out-of-band PSK provisioning mechanism could be susceptible to key recovery by monitoring the network connection (physical or wireless), and extracting the keys as they are exchanged.

DTLS Using Certificates

As DTLS was built based on the TLS protocol, it inherently supports the use of X.509 and OpenPGP certificates for providing data encryption services. Certificates are built by providing information about a specific device, which is then verified and signed by an external Certificate Authority (CA) to build a chain of trust. This chain of trust can then be used for device authentication purposes. By using certificates, DTLS can provide both device authentication and data security, at the expense of the added overhead of supporting certificate-based encryption.

When certificates are used with DTLS, the certificates need to be present on both the client and server devices before a successful DTLS session can be established. Certificates, like Pre-Shared Keys, can either be installed on devices during manufacturing or after device deployment by use of an out-of-band mechanism, which will allow client and server devices to exchange certificates as needed prior to establishing the DTLS session.

As certificates and certificate chains tend to be large in size, they require that devices have adequate non-volatile storage to hold the certificates, additional system memory, and CPU resources for managing the certificates. If an out-of-band mechanism is used for loading certificates onto devices, additional network bandwidth will also be required for the exchange. Additionally, certificates are generally validated using both the certificate and chain of trust (which will include all certificates that were used in the process of signing the certificate being validated), along with a DNS-based Authentication of Named Entities (DANE) system for verifying that a certificate belongs to a specific device.

Raw Public Keys

To reduce some of the complexities of using certificates with DTLS, RFC 7250 has proposed the use of Raw Public Keys, which are essentially a subset of a complete certificate/certificate chain that can be used to secure M2M communications. The Raw Public Key contains only the SubjectPublicKeyInfo structure of a certificate, and omits all other certificate information, yielding a much smaller certificate that can be installed on devices and exchanged during DTLS session initiation. Due to the reduction in size of the certificate, network bandwidth and device storage requirements are greatly reduced, however the certificates lose some of their ability to authenticate devices, and still require the use of an out-of-band mechanism for device authentication, such as DANE.

Using CoAP over a DTLS Secured Network

While CoAP and DTLS have been designed to work together within a constrained environment, it should be noted that they are two separate protocols, and no direct relationship between the two protocols exists at this time. CoAP has been designed as an Application Layer (layer 4) protocol for facilitating M2M communications, while DTLS is designed for securing M2M communications at the Data-Link and Network Layers (Layers 2 and 3).

Typically, when CoAP is used for M2M communications, a CoAP client will generate a CoAP request to a specific CoAP server device. This request is sent directly to a UDP socket, which transfers the request to the CoAP server. When the server receives the request, a response is generated and sent back to the client via UDP. As CoAP is a stateless protocol, this constitutes a complete CoAP exchange. This request/response exchanged is continued until the client no longer has requests, at which time communications between the client and server cease.

When DTLS is used to secure a CoAP exchange, the concept of a session is introduced into the protocols. While CoAP is a stateless protocol, DTLS is stateful, meaning that every time a DTLS connection is established, a session is initiated, which remains active between the client and server until the connection is manually closed by either the client or server, or the session times out due to inactivity. When using DTLS, it becomes necessary for the client and server to have common information loaded that can be used for DTLS encryption, such as Pre-Shared Keys or certificates. As previously noted, this information can either be preinstalled on the devices during the manufacturing process, or exchanged between the devices after deployment using an out-of-band mechanism. Many processes and mechanisms have been defined in the past for preinstalling this information; however, in the context of the Internet of Things, where billions of devices are expected to participate in the network, this concept will soon become unfeasible if manufactured devices are to allow for open but secure communications. That being said, the development of a secure out-of-band mechanism for device provisioning and management would be ideal for allowing devices to be secure, yet remain open and accessible.

To summarize how CoAP and DTLS work together in a DTLS-secured CoAP exchange: After a client generates a CoAP request, the request is sent to the DTLS stack. When the DTLS stack receives the requests, a DTLS session is established between the client and destination server, and a session handshake is performed. After the session handshake succeeds, the CoAP request is encrypted using the security mechanism agreed upon by the client and server, and the encrypted request is sent to the server via UDP. When the server receives the encrypted request, the request is decrypted, and sent to the CoAP stack, where the request is processed and a response is generated. The response is then sent to the DTLS stack for encryption before being sent back to the client using UDP. When the client receives the server response, the CoAP exchange has been completed, however the DTLS session remains active, regardless of whether or not the CoAP client has additional requests to send.

Because of the disjoint nature of the CoAP and DTLS protocols, it becomes necessary to define a bridge between the two protocols, specifically for use during device security provisioning and communication link establishment between two devices. This bridge needs to be capable of filling in all of the deficiencies between the two protocols, allowing them to interoperate without defining any modifications to either protocol. Some of the deficiencies that this bridge must address are:

  • A mechanism for provisioning devices with security information after deployment, allowing devices to exchange security information prior to M2M communications
  • A mechanism for managing device authentication during initial M2M communications
  • A mechanism for controlling M2M communications, including session creation and destruction
  • A mechanism for managing device access control to facilitate privacy control

This bridge must be built in such a way that device and data security are both maintained to the highest degree possible, while enhancing and enforcing user privacy. This bridge must also be capable of allowing constrained devices to communicate using existing network technologies, and must be able to function in both a traditional client/server network environment, as well as a mesh network environment. Finally, this bridge must allow all CoAP and DTLS features to function correctly, and be able to support both PSK and certificate-based security mechanisms.

Device Provisioning

When devices are first deployed as a part of the Internet of Things, they will not have any security information preinstalled, nor will they have been authenticated. When the devices are first connected to the IoT, they must have a mechanism that will allow them to request and retrieve necessary security information, which may include PSKs or certificates that will be used to initiate secure M2M communications.

To allow a device to be provisioned, a device should first contact the nearest IoT server device (which may be another client device on the same network) and request that the device receive security credentials. This request will be used to:

  • Authenticate that a device is legitimate and allowed to connect to the network, and
  • Provision the device with necessary security information to facilitate DTLS communications

Utilizing the existing CoAP technology, a device should first make an unsecured CoAP POST request to the server at coap://[ServerHost]/.well-known/dtls-register. When the device initiates this request, the device should include information about itself that can be used by the server for authenticating the device, purpose of the device, and the type of security that the device requires. Information that this request should include:

  • The device’s hostname or FQDN – This will be used to identify the device
  • The device’s MAC or Serial Number – This will be used to identify the device, and associate a specific device to a hostname or FQDN
  • The device’s type or purpose – This will be used to identify the device’s purpose and/or capabilities, acting as a hint to other devices about what this device does. This is an arbitrary field at this point, and may not be necessary, as other protocols (including CoAP) have mechanisms for providing similar information. This may, however, be useful for logging information about a device during the registration process.
  • Security Type – Defines if the device would like to use PSKs, Certificates, and/or Raw Public Keys for DTLS security. A device may not have the resources for using a certificate-based security approach, or may want to use multiple security formats.
  • Access Privileges – The privileges a device is requesting to use. Devices may support read-only, write-only, or read/write permissions. This will allow basic access control to be supported.
  • Additional Certificate/Raw Public Key information – If a device is requesting to be provisioned with certificates or Raw Public Keys, additional information may need to be sent to the server to allow the server to properly generate the security information.

When a server receives a Register request, it should first perform device authentication. After a device has been successfully authenticated, the server should determine the type of security that the device has requested (PSKs or certificates), and send the security information back to the client. To circumvent issues with key/certificate recovery during the registration process, the server should use a simple encryption mechanism to encrypt the contents of the CoAP response. The server could use a combination of the device’s hostname/FQDN and Mac/Serial number to generate a reproducible password for this encryption, which the client could easily decrypt. The specific encryption algorithm to be used has not yet been chosen, but should be relatively fast to use and simple to implement in a constrained environment. The purpose of this encryption is to verify that PSKs and certificates are not sent in the clear, and to make sure that this information cannot be easily discerned by prying eyes.

Provisioning with Pre-Shared Keys

If a device requests to use PSKs with DTLS, the server should send a list of acceptable PSKs back to the client. These PSKs should be automatically generated by the server and associated with an authenticated client, and should not be hard-coded. Unique PSKs should be generated for each new client, and should be regularly regenerated for provisioned devices after a period of time, allowing PSKs to become temporal and bound to specific clients. This will allow devices to use the basic PSK technology for security, while guaranteeing that PSKs cannot be copied onto unauthenticated devices and continue to work for an extended period of time. This also adds a layer of accounting to the PSK technology; by associating a PSK with a specific client, DTLS sessions can be tracked back to a specific registered device if necessary.

Provisioning with Certificates and Raw Public Keys

If a device requests to use certificates or Raw Public Keys with DTLS, the server will be responsible for generating and signing the requested certificate/key and sending it back to the client (including the complete certificate chain if necessary, Raw Public Keys do not require the certificate chain). When the client makes the initial registration request, the request should include a Certificate Signing Request. This request will be generated by the client device, and will include all of the necessary information to generate a valid certificate. Certificates generally include the following information:

  • Country Code – The 2 letter country code the device is located or was manufactured in
  • State/Province – The state or province the device is located or was manufactured in
  • Locality Name – The city or locality the device is located or was manufactured in
  • Organization Name – The organization that owns or manufactured the device
  • Organization Unit Name – The specific part of an organization responsible for the device
  • Common Name – The Fully-Qualified Domain Name (FQDN) associated with the device
  • Email Address – An email address to contact the device administrator by

When a certificate is generated and signed by the server, additional information is added to the certificate, notably:

  • Certificate Issuer – The name of the server/certificate that was used to sign the certificate. This is used to build the chain of trust that is used to validate a certificate
  • The validity period – A period of time the certificate is valid for before it expires

Unlike PSKs, certificates already include information to associate the certificate to a specific client, as well as an expiration time. This information can be used for accounting purposes, and can be used to force devices to periodically re-register on the network once a certificate has expired.

In both the PSK and certificate/key scenarios, a question arises regarding how long the security information should be valid for. This is a hard question to answer, as it depends entirely on the use case of each individual client device. Some devices, such as washing machines and desktop computers, are relatively fixed. If connected to a network, it is likely that the device will remain connected to the same network for a long period of time. In this situation, it would be adequate to allow the device to continue to use its security information for longer periods of time; months, years, or even indefinitely. Other devices, such as laptops and cellular phones, may be mobile, and frequently connect to multiple networks and devices, or go offline for extended periods of time. In these situations, it would be ideal to keep security information valid for a shorter period of time, and force the device to frequently re-register.

To fully answer this question, it becomes necessary to research various devices and use cases to determine a standard period of time(s) that security information should be valid for. Different device types may require different validity periods, so this should be based on each device’s type/purpose. To define a default period of time, security information should be allowed to remain valid for up to 30 days, to coincide with current network billing practices (specifically, cellular network and internet service providers usually bill their customers on a monthly basis). This would require devices to re-register once per billing cycle, which could be useful for accounting purposes.

Finally, there may come a time that a device needs to leave the IoT network, and remove all of its security information from a registration server. In the event that a client device wishes to be removed from the network, the client should send a CoAP POST to the server it registered with at coap://[ServerIP]/.well-known/dtls-unregister. This request should not contain any additional information. When a server device receives the unregister command, the server will immediately invalidate the client’s security information, and close the current DTLS session without sending a response back to the client. After the client issues the unregister command, it should immediately remove all stored security information for the server.

Device Authentication

Prior to allowing a device to register as part of the IoT network, a device should first be authenticated to verify that the device is truly allowed to join the network and take part in M2M communications. When the initial client registration request is received by a server, the server should first check to see if the client has already registered with the network. If so, the registration process should be halted if the client’s previous registration information has already been issued and is still valid. If the client has not already registered, the server should use the information in the request to validate that:

  • The client device’s hostname/FQDN and MAC/serial number are legitimate
  • The client will respond to requests made to the client’s hostname/FQDN
  • The client’s device type and supported/requested security protocols are adequate for use on the network
  • In the case of certificates/raw public key usage: The information supplied in the registration request matches the information supplied in the Certificate Signing Request (CSR)

Additional checks could be performed at this point to validate a device, such as verifying that the device’s manufacturer/organization (as supplied in the CSR) are allowed to connect to the server. A server could maintain a black/white list of acceptable organizations that could be used for this.

After a device has been authenticated, the information from the registration request should be logged by the server device and associated with the security information that is generated for the client before the information is actually sent to the client. By logging this data, clients can be better accounted for. This additional accounting information could later be used for a variety of purposes:

  • Device tracking – Logging all M2M communication times and/or data for a specific device. If security information for one client is used by a second client, one or both clients could be blacklisted from the network and flagged as rogue devices.
  • Security enhancements/revocation – Modifying or revoking security information on the client

After the registration process has been completed, this information should be retained by the server device until the client’s security information has expired. At this point, the server should revoke and discard the client’s security information (delete PSKs and certificates associated with the client). This will disallow all further communications by the client device until the client registers with the server again. Information that has been logged about a registered client after the registration process (Example: access logs), should be retained for a longer period of time, and be periodically removed from the server as the information becomes stale or unused, or has been extracted from the server device for further accounting purposes.

M2M Session Management

When a client makes its first request to a server, the client will be responsible for initiating a DTLS session with the server. This does not require any additional work on the client’s part, as it is built into the DTLS protocol. When the first CoAP request is transmitted, the DTLS protocol will perform the DTLS handshake and exchange security information with the server. After a DTLS session is created, the CoAP request will be sent to the server, and the server will send a response back to the client. If a subsequent client request is sent to the same server, the DTLS session that is already active should be reused, rather than creating a new session. By default, securing CoAP using DTLS requires that every CoAP exchange uses a new DTLS session, as both protocols use UDP, and therefore, every device must act as both a server and a client. This is very inefficient, as it forces clients to negotiate a new session for every exchange, resulting in excessively high memory, CPU, and network bandwidth utilization for every request made.

A mechanism must be implemented such that, if a client initiates a new DTLS session with a server, that the client and server both have the ability to keep track of the DTLS session ID, and reuse the initial session for sending a response back to a client. This session should also be reusable by the client for subsequent requests/responses, until the client has finished performing its exchanges, and requests that the session is closed.

As previously mentioned, when a CoAP device is secured using DTLS, a DTLS session is created that may remain active longer than a client actually needs it for. These DTLS sessions require system resources, which remain allocated as long as the session is active. This means that every DTLS session will utilize system memory, CPU time, and network sockets, even if the session is sitting idle. Client devices will require a mechanism for manually terminating these DTLS sessions after the client has finished all CoAP exchanges with the server. To manually terminate a DTLS session, a client should send a DTLS-Secured CoAP GET request to the server at coap://[ServerIP]/.well-known/dtls-close, with no additional parameters. Each DTLS session includes a session ID, which is unique to each DTLS session. When a server receives the secured Close request, the server will retrieve the session ID from the DTLS session associated with the request, and immediately terminate the DTLS session. The server will NOT send a response to this request, as the secured session would already be closed, and sending a response back to the client would require initiating another DTLS session.

Access Control

To address issues with device and data security, as well as user privacy concerns, it becomes necessary to implement some form of access control between devices in the IoT. When a device is authenticated and registered with another device, the client device will request certain access control privileges, which could allow the client to have read and/or write access to the server. There may be situations where a server does not want to allow client devices to read or write to it, specifically in the scenario where two devices are manufactured by different manufacturers. To clarify the concept of read and write access, a device read could be translated as being equivalent to a CoAP GET request, where a client is just asking for data, whereas a device read could be considered a CoAP POST request, where a client is sending additional data along with the request.

By default, all registered devices should have read only (CoAP GET) access to all other devices. This will allow all devices registered on the network to query and read data from other devices on the network, regardless of who manufactured or who owns the device. By the time a device has been registered on the network, the device should have already been authenticated, so this should have minimal security implications.

Special considerations need to be taken for devices that have requested write access (CoAP POST) to other devices. When a client requests write access, the access should only be granted to write to the server that the device is registered with, and not to all devices on the network. If a device were granted global device write access, it would be very easy for a rogue device to register with a network, and then use another device in the network as a proxy to gain write access to a remote device, thus allowing the rogue device to write to the remote device in a malicious manner. If a device needs write access to a different server, it must first register with the remote device and request write access. This will help prevent rogue devices from wreaking havoc on a secured network.

Potential Risks and Mitigation Strategies

Every network communication protocol, while useful in their own rights, has its own set of potential risks that it introduces into a secure network environment. In the constrained IoT, these risks can have a large impact on the functionality of the all devices in the network, and the network as a whole. With respect to the CoAP and DTLS protocols, some of the biggest risks that need to be addressed are:

  • Network Bandwidth Usage
  • Device Physical Requirements
  • Rogue Network Devices
  • Denial of Service Attacks

Network Bandwidth Usage

While the CoAP and DTLS protocols are both designed to use as little network bandwidth as possible, they still use bandwidth. This bandwidth utilization increases as the security between the devices does. When DTLS is used with PSKs, the network bandwidth is minimized; however, if certificates are used for DTLS security, bandwidth usage can significantly increase, specifically during DTLS session initiation, when the client and server are exchanging certificates.

When a client is deciding what type of security mechanism to use, the client must decide what will be an appropriate level of security based on the capabilities of the device. A tiny embedded device that has a very limited CPU and memory with a low bandwidth cellular network connection should utilize a lighter security mechanism, such as PSKs or Raw Public Keys for security, whereas, a larger device with ample CPU, memory, and networking resources to spare would be better suited for using certificates and a complete certificate chain for security.

The decision of what type of security to utilize should also be based on the criticality of the data that the device is sending and receiving: A read-only temperature sensing device would be more than secure by using PSKs, while a read/write PLC controlling the cooling system of a nuclear reactor should use a complete certificate chain. The decision of security types to support should be left up to each individual device manufacturer to specify.

Another way to reduce network bandwidth utilization would be to implement the DTLS session reuse mechanism described above in the Device Authentication session, as well as limiting the number of active DTLS sessions that a device will allow at any given time. In a network such as the IoT, devices may be connected to one or more devices (depending on whether a client/server network or a mesh network is implemented). A device should limit the number of simultaneous DTLS sessions to no more than 15 at a time. This will still allow multiple devices to communicate with a single device at a time, but will reduce the amount of data being sent to/from any one device at a time, which will help limit excessive bandwidth utilization at any given time.

Device Physical Requirements

Devices deployed in the IoT, in most cases, will have limited onboard flash/eMMC storage space and small CPUs/MCUs, capable of performing a very small amount of work at a time. To avoid overtaxing a deployed device, a device should limit the number of client devices that it allows to register to 15 or less, especially if these client devices are using certificates for DTLS security. By limiting the number of allowed client devices, a server device will only be responsible for storing a small amount of data for each device, and will not have to perform as many expensive calculations or lookups as it would if the device allowed hundreds of unique clients to be registered at a time. When paired with the maximum simultaneous connection limit defined above, this will allow up to 15 devices to register and communicate with a single server at any given time.

While a device may allow up to 15 devices to register, the device may not necessarily have enough storage space available for storing the client’s authentication and security information. In the event that a server device does not have enough storage space remaining to register a device, the registration process should be aborted immediately.

Rogue Network Devices

A rogue device is a device on the network that is falsely registered. The device could have been registered by using a stolen PSK, or an invalid/copied certificate that does not match the host system. In the event that a rogue device is detected by the server, the server should immediately remove the device from the network, and blacklist the device to indicate that the device should not be allowed to communicate. The issue of rogue devices should be addressed during device registration/authentication, where a device is required to send identifying information about itself as part of the registration process.

Denial of Service Attacks

Denial of Service (DoS) attacks could be launched against IoT devices by targeting multiple different components of the CoAP and DTLS protocols. The first mechanism a device could attempt to attack would be the registration process. A malicious device could attempt to flood a server device’s registration service, either by sending large amounts of good or bad registration requests to the server, which would cause the server to allocate extra CPU and memory resources for the registrations. This could also increase network bandwidth usage, causing issues with legitimate devices on the network that are attempting to access the server device.

To circumvent this issue, a server device should only allow any one device to attempt to register up to three times before the device is blacklisted. This will give a client device up to three attempts to successfully register with the server. If after the third attempt a device is still not registered with the server, the server should ignore any further registration attempts by that device for a period of 24 hours. This will reduce the potential for DoS attacks to be launched against the registration service.

A device could also initiate a DoS attack after it has successfully registered on the network by continuing to send registration requests to the server device. If a server device receives a registration request from a device that it has already registered in the past, and the previous registration for that device is still valid, the server should ignore and drop the registration request. If the client device continues to attempt to register on the network, the server should blacklist the client device after three registration attempts have been performed, just as it would if the device was not registered.

References

  • “Internet of Things.” Wikipedia. Wikimedia Foundation, 1 July 2015. Web. 2 July 2015. <https://en.wikipedia.org/wiki/Internet_of_Things>.
  • “Constrained Application Protocol.” Wikipedia. Wikimedia Foundation, 9 June 2015. Web. 2 July 2015. <https://en.wikipedia.org/wiki/Constrained_Application_Protocol>.
    Shelby, Z., K. Hartke, and C. Bormann. “RFC 7252 – The Constrained Application Protocol (CoAP).” RFC 7252 – The Constrained Application Protocol (CoAP). Internet Engineering Task Force, 1 June 2014. Web. 2 July 2015.
  • “Datagram Transport Layer Security.” Wikipedia. Wikimedia Foundation, 19 June 2015. Web. 2 July 2015.
  • Rescorla, E., and N. Modadugu. “RFC 4347 – Datagram Transport Layer Security.” RFC 4347 – Datagram Transport Layer Security. Internet Engineering Task Force, 1 Apr. 2006. Web. 3 July 2015.
  • Rescorla, E., and N. Modadugu. “RFC 6347 – Datagram Transport Layer Security Version 1.2.” RFC 6347 – Datagram Transport Layer Security Version 1.2. Internet Engineering Task Force, 2012. Web. 3 July 2015.
  • “RFC 7250 – Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).” RFC 7250 – Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Internet Engineering Task Force, 1 June 2014. Web. 3 July 2015.

Like this article? Feed the developer, every dollar counts: