Tag Archives: computer communication protocols

MQTT not IoT “god protocol,” but getting closer

One protocol, and its descendants, drove the success of the World Wide Web. IP, or Internet Protocol, is the basis of every browser connection and the backbone of IT data centers. Some assumed that the Internet of Things would follow suit, with the thought that having an IP address would be a sufficient condition to connect.

The problem on the IoT isn’t IP – the problem is all the stuff layered on top of it. Running protocols such as HTTP, SSL, and XML requires significant compute power and memory space. The average PC, smartphone, or tablet has enough horsepower today to do that, but the average sensor running on a smaller microcontroller does not. (ARM Cortex-M7 notwithstanding.)

To combat that, the industry has spawned a huge list of alternative, mostly non-interoperable IoT protocols. A partial list: 6LoWPAN, AllJoyn, AMQP, ANT+, Bluetooth, CoAP, DASH7, DDS, INSTEON, KNX, MQTT, NFC, RFID, STOMP, Thread, Weightless, XMPP, ZigBee, and Z-Wave. New consortia are popping up weekly with more ideas.

Searching for an IoT “god protocol”, one unifying end-to-end protocol serving all things, is silly. At one end, sensors have different requirements such as range, RF spectrum, security, topology, and power consumption. At the other, any successful IoT strategy will ultimately need to integrate with an IP-based cloud in some form. Greenfields of any scale rarely exist. IoT applications need to connect and exchange data.

The answer is building a multi-protocol bridge between sensors and actuators, mobile devices, and the cloud. Ideally, code would be open source, and would provide scalability to span a wide range of devices in large numbers. Additionally, transport would be reliable, surviving brief intermittency in wireless connections.

IBM Internet of Things Foundation

More and more organizations are embracing MQTT as part of the bridge. MQTT offers a full-up version running over TCP/IP, and a slimmed down version MQTT-SN for non-IP devices. Its publish/subscribe model allows topologies to scale while retaining real-time characteristics and configurable quality of service.

IBM started the whole MQTT movement as a message broker for mainframes and servers, with integration into WebSphere for web services. They then opened it up for embedded use in a release to OASIS and the Eclipse Foundation.

A big piece of IBM Bluemix is the IoT Foundation, a cloud-based instance of MQTT with predefined topic structures and message formats. Mobile apps are already using MQTT, with applications such as Facebook Messenger and Salesforce.com. IBM also has an e-book on MQTT in mobile.

Other recent developments to consider:

  • ARM’s mbed device server seeks to replace a generic web server with one tailored for the IoT. Built from technology in the Sensinode acquisition, ARM has brought HTTP, CoAP, and MQTT together in one platform.
  • 2lemetry has taken that a step further with ThingFabric, integrating protocol actors including MQTT, CoAP, and STOMP, along with extensibility.
  • PubNub has taken a websocket connections approach running over MQTT, focusing on low latency, reliable delivery from a cloud implementation. There is a good PubNub guest post on Atmel Bits & Pieces describing the approach.
  • Speaking of Atmel and Arduino, IBM has several recipes for leveraging Arduino with the IoT Foundation, such as an Arduino Uno connection example, and a series on implementing a cloud-ready temperature sensor.
  • Open source motivates many folks, and one of the more interesting individual projects out there is a bridge for AllJoyn to MQTT. If successful, the implications could be significant, such as controlling home entertainment devices directly from Facebook on a mobile device.

Again, I don’t think there is a “god protocol” that will take over the IoT once and for all, satisfying each and every use case. The winners are going to integrate multi-protocol bridges to serve as wide a range of use cases as possible. The ability of MQTT to connect sensors and mobile devices to big data systems in real time is drawing more participants in.

This post has been republished with permission from SemiWiki.com, where Don Dingee is a featured blogger. It first appeared there on November 5, 2014.

What is the Difference Between Encryption and Authentication?

By: Gunter Fuchs

Not considering how to actually do encryption or authentication, it is fairly simple for a native Latin speaker (http://www.etymonline.com/index.php?term=authentic, http://www.etymonline.com/index.php?term=crypto) to distinguish between the two. We authenticate something to prove to the receiver of the “something” that it actually came from us. We encrypt a message so nobody, including us, can read it. Why do we authenticate or encrypt? We authenticate so that the receiver is assured that what she received came from us and not from an imposter. This “thing” can be an item – a coin or painting for instance, or a piece of information, an email attachment or a speed command to a uranium centrifuge. We encrypt information so that only the intended receiver(s) can understand it.

So that was simple. But why do computer gurus go through great efforts to provide means of information authentication? Wouldn’t encrypting information be enough? Couldn’t the sender just include its name and address in the information and then encrypt? Well, no. The problem is that although a “man in the middle” will not understand the information, he will still be able to change it. For instance, in computer communication protocols a destination address (port) might be at a fixed position in a message. An adversary could copy such a message when it is on its way through some wire, change this value randomly, and monitor its own port/s until one of these messages – though still garbled – arrives. Once the adversary has received one message, he can now inject the encrypted port value for his own port for every message. One message would not be enough for a hacker to perform decryption,  but many makes this possible.  Not only would an adversary then be able to decipher messages that were not meant for her, but she can now also “break the code”, meaning deduce the encryption key. And with that key in hand, she can now send messages that are not authentic.

Therefore, a secure communication consists of authenticating the message and encrypting it.  To learn more about the importance of protecting your trade secrets, check out this white paper.