Why are IoT developers confused by MQTT and CoAP?

This is a guest post by Jonathan Fries of Exadel.

Originaly published in TechTarget.

Recently, at Exadel, we encountered an interesting challenge for IoT developers. Because IoT apps have gained so much momentum, there is more and more choice in how to develop them. For device communication, two specialized, competing protocols stand out: Message Queue Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP). They’re both designed to be lightweight and to make careful use of scarce network resources. Both have uses, in the correct setting, but the problem is that, due to the relative infancy of IoT development, people don’t know exactly what these protocols are or when to use them.

These are not standard web protocols that everyone uses.

In light of our own internal conversations, I decided I’d like to help demystify these a bit. First, let’s look at what these protocols actually are.

What is MQTT?

To the layperson, MQTT is a lot like Twitter. It is a “publish and subscribe” protocol. You can subscribe on some topics and publish on others. You’ll receive messages on topics you subscribe to and those who subscribe to the topics you publish will receive those messages. There are differences, of course. For instance, you can configure the protocol to be more reliable by guaranteeing delivery. The publish/subscribe system utilizes a broker, which, to further draw out the analogy, would be the Twitter platform itself — filtering the messages based on your subscription preferences.

What is CoAP?

CoAP is more like going to a traditional website-based business, like Amazon. You request resources (pages and search results in the Amazon example) and occasionally also submit your own data (make a purchase). CoAP was designed to look like and be compatible with HTTP which powers most of the internet as we currently know it. CoAP can either utilize proxy servers and be translated into HTTP or communicate directly with a special server designed to use CoAP, depending on the environment constraints.

When do you use them?

The question you’re probably all asking is, “if they’re so similar, when should I use one versus the other?”

MQTT is ideal for communicating between devices on a wide area network (WAN, internet) because of the publish/subscribe architecture with the broker in the middle. It is most useful in situations where bandwidth is limited, such as remote field sites or other areas lacking a robust network. MQTT is a part of Azure and Amazon service offerings, so it has a lot of established architecture, making it easily adapted for current developers.

In the case of CoAP, the strongest use case is its compatibility with HTTP. If you have an existing system that is web service-based, then adding in CoAP is a good option. It is built on User Datagram Protocol (UDP) which can be useful in some resource-constrained environments. Because UDP allows broadcast and multicast, you can potentially transmit to multiple hosts using less bandwidth. This makes it good for local network environments where devices need to speak with each other quickly, which is traditional for some M2M settings.

If an IoT developer is working with a device that is going to leverage an existing web server architecture, the developer will use CoAP. But if the developer is building something where a device is really “report only” — that is, it is dropped on the network and just needs to report data back to a server — CoAP will be better for that. Other uses, such as cloud architecture, will probably best be done with MQTT.

The future of MQTT and CoAP

Over time, for other protocols, usage or industry adoption has tended to migrate toward the more free and inclusive platform, unless the non-inclusive one is much better. Both MQTT and CoAP are open standards which anyone can implement. CoAP was started by a standards body as opposed to MQTT which was originally designed by private companies, including IBM. CoAP has been designed to handle resource-constrained environments and it may be that it becomes the winner, but for the time being MQTT seems like it is in the lead. There is significant momentum behind MQTT — the big cloud players have picked it, or at least picked it initially. Additionally, many commercial use cases need the features of MQTT (store and forward, centralized host). However, one possibility is that some software development that has standardized around HTTP (mobile app development for instance) could start to leverage CoAP both for working with peripherals and to communicate to the back end to help reduce bandwidth on bad connections.

Ultimately, these protocols can be effectively deployed in different applications through the internet of things. We know that there are specific use cases in which each is best served, but we also know that IoT and IoT devices will continue to grow in complexity and ubiquity. For developers, understanding the key differences in application can not only enable a better initial deployment, but build a strong foundation onto which future development can be executed.

All HYKER blog contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of HYKER Security.

Security Recommendations For IoT By BITAG

This is an extract of the excellent BITAG report “Internet of Things (IoT) Security and Privacy Recommendations”, published courtesy of BITAG, Broadband Internet Technical Advisory Group.

We highly recommend downloading and reading this report. And, even more importantly, to implement these recommendations, where the Apptimate platform can be a valuable part of your developer toolkit.

The full report can be found here.

BITAG believes the recommendations outlined in this report may help to dramatically improve the security and privacy of IoT devices and minimize the costs associated with collateral damage. In addition, unless the IoT device sector—the sector of the industry that manufactures and distributes these devices—improves device security and privacy, consumer backlash may impede the growth of the IoT marketplace and ultimately limit the promise that IoT holds.

BITAG recommended several security standards for IoT devices, including timely, automated software updates and password protection. The organization also said there should be more testing of customization options and an implementation of encryption best practices. BITAG also highly recommended allowing IoT devices to function if internet connectivity or the cloud fails, especially in the case of home alarm systems.

In the past few years, many devices now being connected to the Internet are not only personal computers but also a variety of devices embedded with Internet connectivity and functions. This class of devices has generally been described as the Internet of Things (IoT) and has brought with it new security and privacy risks.

Although consumers face general security and privacy threats as a result of any Internet-connected device, the nature of consumer IoT is unique because it can involve non-technical or uninterested consumers; challenging device discovery and inventory on consumer home networks as the number and variety of devices proliferate; negative effects on the Internet access service of both the consumer and others that run on shared network links; and effects on other Internet services when these devices are compromised by malware and become a platform for unwanted data traffic—such as spam and denial of service attacks—which can interfere with the provision of these other services. Importantly, the number and diversity of consumer IoT devices is growing rapidly, and these devices often function autonomously, without human intervention.

Several recent incidents have demonstrated that some devices do not abide by rudimentary privacy and security best practices. In some cases, devices have been compromised and allowed unauthorized users to perform Distributed Denial of Service (DDoS) attacks, perform surveillance and monitoring, gain unauthorized access or control, induce device or system failures, and disturb or harass authorized users or device owners.

Potential issues contributing to the lack of privacy and security best practices include: lack of IoT supply chain experience with security and privacy, lack of incentives to develop and deploy updates after the initial sale, lack of secure over-the-network software updates, devices with malware inserted during the manufacturing process, and more.

Recommendations

IoT Devices Should Ship With Reasonably Current Software

BITAG recommends that IoT devices should ship to customers or retail outlets with reasonably current software that does not contain severe, known vulnerabilities.

IoT Devices Should Have A Mechanism For Automated, Secure Software Updates

Software bugs should be minimized, but they are inevitable. Thus, it is critical for an IoT device to have a mechanism for automatic, secure software updates.  BITAG recommends that manufacturers of IoT devices or IoT service providers should, therefore, design their devices and systems based on the assumption that new bugs and vulnerabilities will be discovered over time. They should design systems and processes to ensure the automatic update of IoT device software, without requiring or expecting any type of user action or even user opt-in.

IoT Devices Should Use Strong Authentication By Default

BITAG recommends that IoT devices be secured by default (e.g. password protected) and not use common or easily guessable user names and passwords (e.g., “admin”, “password”).

IoT Device Configurations Should Be Tested And Hardened

Some IoT devices allow a user to customize the behavior of the device. BITAG recommends that manufacturers test the security of each device with a range of possible configurations, as opposed to simply the default configuration.

IoT Devices Should Follow Security & Cryptography Best Practices

Manufacturers should take care to avoid encryption methods, protocols, and key sizes with known weaknesses. Additional encryption best practices include:

  • Encrypt Configuration (Command & Control) Communications By Default
  • Secure Communications To and From IoT Controllers
  • Encrypt Local Storage of Sensitive Data
  • Authenticate Communications, Software Changes, and Requests for Data
  • Use Unique Credentials for Each Device
  • Use Credentials That Can Be Updated
  • Close Unnecessary Ports and Disable Unnecessary Services
  • Use Libraries That Are Actively Maintained and Supported

IoT Devices Should Communicate Securely

IoT Devices Should Be Restrictive Rather Than Permissive In Communicating

When possible, devices should not be reachable via inbound connections by default. IoT devices should not rely on the network firewall alone to restrict communication, as some communication between devices within the home may not traverse the firewall.

IoT Devices Should Continue To Function If Internet Connectivity Is Disrupted

BITAG recommends that an IoT device should be able to perform its primary function or functions (e.g., a light switch or a thermostat should continue to function with manual controls), even if it is not connected to the Internet because Internet connectivity may be disrupted due to causes ranging from accidental misconfiguration to intentional attack. IoT devices that have implications for user safety should continue to function under disconnected operation to protect the safety of consumers.

IoT Devices Should Continue To Function If The Cloud Back-End Fails

Many services that depend on or use a cloud back-end can continue to function, even if in a degraded or partially functional state, when connectivity to the cloud back-end is interrupted or the service itself fails.

Manufacturers should support an IoT device throughout the course of its lifespan, from design to the time when a device is retired, including transparency about the timespan over which they plan to provide continued support for a device, and what the consumer should expect from the device’s function at the end of the device’s lifespan.

More detailed recommendations can be found in the report here.

The Value Of Smart Home Data

If you own your house and turn it into a Smart Home then it is quite simple; You own your data. And it will be valuable. You have all the rights to sell it or trade it to different service providers, like the power, cable or home security company. Maybe you don’t think about that every time you sign a contract for a service, but you should read the small print and see that you get value for your data. Or the service provider might try to generate value from your data without giving anything back to you.

But if you rent your place then things get more complicated.

Read More