Archive: May 2017

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.

On Friday last week, the world was hit by a global ransomware campaign of unprecedented proportions. That campaign has now infected over 10,000 organizations and 200,000 individuals in 150 countries. This includes the UK National Health System that has been highlighted in media.

On Friday a researcher analyzing the code stopped the ransomware from spreading by registering a domain that served as a kill switch for the ransomware.

It wasn’t long before new variants of the WannaCry ransomware started emerging. One of the variants was also stopped today by registering a kill switch domain, the same way the ransomware was stopped on Friday. A second variant is not encrypting infected machines due to an error in programming, but it is spreading.

We expect new variants to emerge all week that continues to exploit the vulnerability in the Server Message Block (SMB) that WannaCry has been using.

How to protect yourself against WannaCry

If you use old unsupported Windows versions, like Windows XP, Windows 2008 or Server 2003, install the patch that Microsoft has released to block the specific exploit that the WannaCry ransomware is using. You find it here: Microsoft Security Bulletin MS17–010.