IoT Broker

The IoT Broker is a message broker that helps ensure things connected to the Internet has a secure, open and interoperable communication environment. It does this by:

• Using XMPP, providing things with a distributed, federated communication network that solves basic authentication and authorization. XMPP is very capable, and provides a standardized middleware layer for internet applications that require real-time communication support. Using XMPP replaces the need for customized middleware with replaceable components.
• Providing a Thing Registry for things to be securely claimed by their owners. The Thing Registry matches ownership claims to unclaimed devices, and informs matching pairs about the network identities of each other. Once claimed, a thing can be made public. They are allowed to publish their existence and capabilities, allowing consumers to find suitable things based on their capabilities.
• Providing Decision support for things in a changing environment. This allows owners to determine who can access their things, what fields they are allowed to read and what parameters they are allowed to control.
• Securing Account Creation for batches of things, to protect against malicious use and unwanted bots.
• Providing federated services for Legal Identities and Smart Contracts for connected entities. This lays the foundation for agreements* between entities, automated provisioning and economic feedback for owners based on usage of their devices. These legal identities can also be used in Multi-Factor Authentication by third parties wishing to integrate them in their applications and services.
• Interoperability based on Neuro-Foundation XMPP IoT Interfaces.
• Multiple client libraries available on nuget.org, with source code available in the IoT Gateway repository on GitHub.
• Since it is built on the IoT Gateway, it is extensible. You can host your own back-end applications and services on the broker using .NET Core, as well as publish extensible web content using Markdown and Script.

Using this IoT Broker allows you to create open, yet secure and interoperable applications for the Internet of Things.

How does it work?

The IoT Broker helps secure the Smart City by providing the following set of services:

Neuro-Foundation IoT Harmonization

The IoT Broker is based on the results of the Neuro-Foundation IoT Harmonization effort. The goal is to create open standards that facilitate the interoperable communication of things across the Internet, in a secure manner. Interfaces and descriptions are made available at the Neuro-Foundation repository.

Federation

The infrastructure is federated by design. This means that you can freely extend the network by setting up your own integration servers on your own domains using your own domain names. Devices connected to any integration server on the Internet can communicate with any device connected to any other integration server on the Internet, as long as they are authorized to do so. This is possible, since the integration servers cooperate and exchange messages between themselves, in real time, just like mail servers do, but faster. For this reason, Integration Servers are also known as message brokers. They broker messages between entities on the Internet.

Topology Independence

Entities connect outward to their assigned message broker. Never do things need to establish different connections depending on who they communicate with. All messages sent and received are passed over the same connection. Never do entities need to accept incoming connections. This allows things and users to reside behind firewalls. Since message brokers interconnect and exchange messages, things and users can reside behind different firewalls, connect to different message brokers, and still communicate with each other.

Global Scalability

The federated nature of the infrastructure also provides a natural way for it to grow organically. It is not necessary to create huge complex data centres that host services for everyone at once. Instead, anyone can host their own set of message brokers, without affecting the network performance of others needlessly. At the same time, this is done without restricting who entities can communicate with. Message brokers collaborate to form a global network of interconnected things.

Resilience

Federation is also a great tool for creating resilient networks, as you divide the risks across the network. The failure of a message broker only affects a small portion of the entire network, just as a router only affects a small part of the larger interconnected network.

Open Standards

Basing the infrastructure on Open Standards has several advantages: Infrastructure components become replaceable and exchangeable. It also removes the need for the development of bespoke or proprietary back-end software to make entities interconnect and communicate. It becomes possible to create Smart City applications without the requirement to develop server software or to rely on server-storage of sensitive sensor data.

Neuro-Foundation IoT Harmonization is based on the XMPP protocol, which is an open standard, standardized by the Internet Engineering Task Force, IETF in RFC 6120, RFC 6121 and RFC 6122. XMPP is federated, open, extensible, secure, proven and robust. It is XMPP that defines the basic operation of message brokers. The XMPP Standards Foundation, XSF publish XMPP extensions for different purposes. The Neuro-Foundation IoT Harmonization effort bases its work on these standards, as well as interfaces published in the Neuro-Foundation XMPP IoT Interfaces repository.

Protocol Bridging

Neuro-Foundation IoT Harmonization defines interfaces for concentrators that collect, or concentrate, a set of devices behind a single communication endpoint in the network. This can be used for embedding devices (or nodes) in a single physical device, such as a Programmable Logic Controller (PLC). It can also be used to bridge protocols in real time or connect large back-end systems to the network. Nodes in a concentrator behave just as any other thing connected to the infrastructure, and therefore also benefit from its features such as discovery, decision support, ownership, contracts, and so on.

If you are interested in acquiring protocol gateways between XMPP and any other protocol, such as M-Bus, Modbus, Bluetooth, MQTT, LWM2M, etc., leave a note in the feedback form.

Interoperability

The goal of Neuro-Foundation IoT Harmonization is to provide, as the name suggests, a means to harmonize different IoT-based technologies and allow them to integrate and interoperate, even if they are based on different communication patterns and protocols. This is possible through the concept of bridging, and because XMPP provides a great support for popular communication patterns. Neuro-Foundation IoT Harmonization allows for interoperable communication, not only across topology barriers, but also across technology and protocol barriers.

Global Identities

For an entity to be able to connect to a message broker, it needs an account on that broker. The account name, together with the domain name of the broker, becomes a global identity for the entity. The identity, or address takes the form of what looks very much like an e-mail address: account@domain, also called a Bare Jabber ID, or Bare JID. An entity connected to this broker using an account named my.thing would have a global address of my.thing@waher.se. Once connected, the message broker provides the entity with a random resource string. Together with the Bare JID, this forms a Full JID, in the form my.thing@waher.se/resource.

For concentrators, the Bare JID points to the concentrator itself. A thing that resides in, or behind, a concentrator, is further identified using a Node ID, and optionally by a Source ID and Partition as well. Nodes can reside in sources, which may, or may not be partitioned into segments. The quadruple (Bare JID, Node ID, Source ID, Partition) is globally unique. Node ID, Source ID and Partition are optional

Authentication

Authentication in distributed environments such as a Smart City is typically difficult. Does everyone need to have access to the credentials of everyone else that it is to be able to communicate with?

In XMPP, this problem is delegated to the brokers. One important task they have is to authenticate all clients connecting to them. You cannot send messages to others in the network before the message broker has successfully authenticated your identity. Brokers also annotate all messages forwarded in the network with the address of the source of the message. This identity is very difficult to spoof, as the brokers also mutually authenticate each other and reject messages not annotated with a source address corresponding to the domain of the emitting broker. This allows the receivers of messages to estimate the validity of a received message simply based on the trust it places on the immediate broker, which is only one.

Simply put: The infrastructure authenticates all participants, and all participants are informed about the authenticated identities of everyone sending them messages. This makes it very easy to make good security decisions in a distributed environment such as a Smart City.

Consent

In order to be able to communicate efficiently with another entity in the network, you need its Full JID, not only its Bare JID. The Full JID is transmitted to approved parties when the corresponding entity reports its presence. This is done, among other things, when the entity comes online or goes offline. The Bare JID can be used to request a presence subscription from the entity, which will allow the Full JID to be known if the entity consents to the request. If the corresponding entity does so, its message broker registers this event, and forwards future presence information to the party making the request. The entity can withdraw the consent at any time, making sure the corresponding party is no longer informed about the Full JID of the entity. When reconnecting, receiving a new resource, the party having lost the presence subscription, will not be able to communicate efficiently with the entity any longer.

Authorization

XMPP includes several authorization mechanisms that help protect entities in the network:

• Only properly authenticated clients are authorized to send messages to the network.
• Only mutually authenticated brokers can participate in the federated network.
• Brokers can only forward messages originating in their authenticated domain.
• Information Queries require the use of Full JIDs, whose reception require mutual consent.

Neuro-Foundation IoT Harmonization adds an authorization layer of decision support to this list.

Secure Registration

To automate the installation and configuration of huge quantities of devices into the network, along the principles of zero-configuration networking for the operator, an automatic registration procedure is available. To prohibit malicious bots from being able to create identities fraudulently, requests must be identified using an API key and signed using a private key. API keys can be limited with regards to the number of accounts that can be created using it.

On this broker, you can request an API key.

Discovery

During production, the manufacturer is only aware of the conceptual identity of the devices being manufactured. This identity can include information about serial number, make and model of device, information about manufacturer, etc., as well as a secret key. Typically, the manufacturer and the device are unaware of the network identity the device will have.

After installation and during configuration, the device will find its broker, either through pre-configuration, or through information available in the network, create its network identity. The device then registers itself with a Thing Registry available on the message broker. This registration contains the conceptual identity of the device, and its new network identity.

The conceptual identity, known at the time of production, is transferred out-of-band to the owner of the device. This can be done using a QR-code (for instance) on a sticker or sharing a iotdisco URI. The owner sends a claim to the same Thing Registry. The registry matches registrations and claims, and if they match, pairs the thing with its owner, and informs each one about the network identity of the other.

Once claimed, the owner can decide if the thing should remain in the registry or not, and if it should be publicly searchable. The thing, as well as the owner, can annotate the thing with tags. This makes it easier to find relevant things. As the thing knows its owner, it also knows who is responsible for making the correct security decisions. The broker also knows who the owner of each claimed device is. This allows the broker to help things make good security decisions.

Ownership

Once each thing knows the network identity of its owner, it becomes possible to define ownership, not only of the thing, but also of the data it generates. Typically, in cloud-based solutions, data ownership is challenging, if not undefined.

Mimicking how ownership of everyday physical objects is defined, or enforced, the infrastructure helps define a method of enforcing ownership of information:

• Local processing of information, together with Ubiquitous Encryption protects it behind lock and key.
• Thanks to the strong support for authorization, access to information is limited to only trusted parties.
• Access is monitored, especially if data is made available through contracts.
• Ownership of information can be demonstrated through annotations in the Thing Registry.

Ownership of information is enforced by utilising the decision support provided by the infrastructure, together with edge computing principles, instead of relying on centralized processing in the cloud, except in cases when required or in accordance with the wishes of the owner.

Decision Support

The infrastructure provides your things with decision support, helping them make security decisions in real time. This provisioning capability allows owners to control who can communicate with their devices and do what with them. It also reduces the responsibility of the manufacturer, who cannot possibly know beforehand for what purpose each device will be used.

When something new happens to a thing, to which it does not know how to react, it can ask the provisioning service in the broker what to do. Designed on the principles of data protection by default, the provisioning service will reject the petition if it does not know how to solve it. But it knows who its owner is, and therefore also, who should know. An asynchronous message is sent to the owner, which the owner can respond to when time is available. Once responded to, the provisioning service learns. The next time the thing asks a related question, the provisioning server knows how to respond. The service has been provisioned in accordance of the will of the owner, and with no impact on the infrastructure operator.

Using the discovery and provisioning features proposed by the IoT Broker, the entire life cycle of the thing is supported. From production, through installation, configuration, production, change of ownership to decommissioning.

Decision support can further be fully automated, using contracts, in accordance with zero-configuration networking principles, and still maintaining a high level of security.

Contracts

Owners can automate decision support by uploading digital contracts for their things. These contracts stipulate requirements that must be met in order to gain access to their devices, under what conditions access can be given, for how long and how often. Identified third parties wanting access to devices can accept their contracts and are automatically granted access in accordance with the contracts. Things report usage to the infrastructure, which uses this usage information to monitor compliance with the contract. This usage information is also used to create billing information or the Marketplace of Things and Data.

Ubiquitous Encryption

Ubiquitous Encryption is a policy that requires that all client ⇔ broker connections (c2s), and all broker ⇔ broker (s2s) are encrypted and properly authenticated. This is one of many features that provide for added security. In cases where very sensitive information is communicated, End-to-end encryption (E2E) and/or Peer-to-Peer (P2P) communication can be used.

Security

The IoT Broker helps you maintain a high level of data protection by design and by default for your Smart City applications. It does so by providing:

• Strong global identities that identify all senders of messages in the network. While anonymous access might protect a whistle blower (or a criminal), strong authenticated identities protect the information owner.
• Authentication of all participants in the network.
• Authorization based on consent is required for full access to an entity. This consent can be verified, and as easily withdrawn, as it was given.
• Federation provides for resilience and scalability. It allows you to divide the risk across domains.
• Ownership and decision support provide long-term security for things that are not operated by humans.
• Ubiquitous Encryption helps maintain the confidentiality of the information communicated.

Edge Computing

Edge computing is the paradigm that information should be processed as close to the edge, or the source, as possible. It is the opposite of centralized (or cloud) processing. The IoT Broker helps you realize the Edge Computing paradigm, by not participating actively in the processing of sensor data. The IoT Broker only acts as a message broker, and furthermore provides registry and decision support services for things. Sensor data is never collected by the broker. If an entity wants access to the data, it needs to request it from the thing directly, helped by the infrastructure to do so. If an infrastructure component should try to collect such information from things integrating with the IoT Broker, their corresponding owners would be alerted, and data collection would only be possible in instances where owners consent.

Privacy

The IoT Broker helps applications respect the privacy of any data subjects related to any sensitive information measured by devices connected to the broker. This is done on an infrastructure level, in several ways:

• Data protection principles are implemented by design and by default.
• Access to data can only be achieved through consent from its owner.
• Any consent given can be as easily withdrawn, as it was given.

Marketplace of Things and Data

The law of supply and demand requires you to limit access to a resource for it to be valuable, i.e. having a price above zero. An unlimited resource has no price, or a price of zero. While the resource might have non-monetary values, such as emotional, philosophical or spiritual values, for it to have a monetary value, access to it must be restricted. This does not automatically mean any restricted resource has a value. But all valuable resources are restricted. And so, it is for information too: Only restricted information can be valuable.

For this purpose, the IoT Broker provides a marketplace of things and data, and helps owners restrict access to their things and their data. Owners publish their things in the Thing Registry where others can discover them. Through contracts, owners define the conditions required of acquiring access to their things. Accepting these contracts is done using a digital signature; a deal is made. The plurality of offerings available in the registry forms a marketplace of things and their data.

Economic Feedback

The integration server provides billing information to the infrastructure operator, based on signed contracts and reported usage. The operator can use this information to bill the parties participating in the network, in accordance with their usage. A part of these earnings is used to reimburse the owners whose devices have been used. This creates an economic feedback, helping the owners to get a return on their investment.

Incentives to develop the Smart City

The original question being solved by the proposed infrastructure is as follows: What incentive does an owner of a thing have for allowing others to connect to it and use it in their systems? In the vision of a Smart City, there’s ubiquitous access to things and services in all niches of society. But what incentives are there for this to occur?

In a traditional IoT system there are few. Allowing third parties access to your things will only put more load on your devices, decreasing the performance of your system, while a competitor can publish a similar service as yours without having to invest in hardware. For this reason, most IoT solutions are closed systems prohibiting integration with their things directly, permitting access at most through controlled back-end server platforms using proprietary APIs. Integrations are therefore limited.

Through the proposed infrastructure, there is a clear economic incentive to allow others access to your things. If you provide the type of device for which others are willing to pay to get access to, you might not only get a return on your investment, but also turn a profit. It will become profitable in its own right, to provide access to devices and their data and services. The marketplace will provide a platform for competition, which will accelerate development of the Smart City.

Why XMPP?

The reasons for choosing XMPP for an IoT backbone are many. Here are some:

• XMPP is standardized by the Internet Engineering Task Force (IETF) in RFC 6120, RFC 6121 and RFC 6122.
• XMPP is encrypted.
• XMPP is battle tested and robust, with 25 years of operation.
• XMPP is extensible. Anyone can extend it without being afraid the extensions will collide with other extensions.
• XMPP has a series of standardized extenions, managed by the XMPP Standards Foundations - XSF.
• XMPP is federated, meaning anyone can set up their own XMPP domain, extending the network without limiting performance of the rest of the network. Federation is the key to global scalability.
• There’s a lot of available software for XMPP, including clients, servers and libraries in most languages.
• XMPP supports both Human-to-Human (H2H), Human-to-Machine (H2M) and Machine-to-Machine (M2M) interfaces.
• XMPP supports most important communication patterns, including:
  • Asynchronous messaging
  • Request/Respond
  • Publish/Subscribe
  • Multicast
  • Event subscription
• XMPP is not sensitive to network topology in the same way as HTTP and CoAP.
• XMPP is secure, in contrast to protocols such as MQTT which due to intrinsic vulnerabilities can never be made secure in an open and interoperable environment such as the Internet.
• XMPP includes a global, distributed identity model, providing actors with their own unique global and authenticated identity. This makes distributed transactions and security decisions easier. Everybody knows the identity of each other.

XEP support by the IoT Broker

The IoT Broker is an XMPP server dedicated to IoT-related applications. It has support for a specific set of protocols to achieve this. The following table lists what server-specific protocols are supported by the broker. (All client-side protocols are by their very nature automatically supported.) The IoT Broker also supports the Neuro-Foundation XMPP IoT Interfaces.

e-Mail Integration

Each account in the IoT Broker, is also a mail account. This means you can mail information to an XMPP client. An XMPP client can also implicitly mail back to a mail client, by sending stanzas to the corresponding mail address. Integration is seamless. Plain text and HTML or Markdown formatted e-mail will be translated automatically to corresponding XMPP message stanzas, and vice versa.

There’s one major difference in how the IoT Broker works with mail, and how normal mail servers work: While both use the Simple Mail Transfer Protocol (SMTP) to send mail messages, the IoT Broker operates using white lists, as opposed to black lists that normal servers operate under. This means that you need explicit approval, or consent, from the recipient, before you can send an e-mail message to a recipient. If such an approval does not exist, the e-mail will not be delivered. Instead, a presence request is issued. The white-list is implemented using presence subscription, just as in the XMPP case. Any XMPP client can add senders to the white-list, by accepting a presence subscription, or subscribing to the presence of an e-mail client. Removal from the white-list is done by simply removing the presence subscription, or corresponding roster item. The e-mail client will be informed of all actions related to its status in the white-list through e-mail status updates.

To be able to send e-mail messages to the IoT Broker, the sender must pass SPF verification (Sender Policy Framework) as defined in RFC 7208. The sender must also pass any DNSBL (DNS Black List) checks set up by the operator.

For more information

For more information on how to build things and services that utilize the infrastructure provided by the IoT Broker, check the following resources.

Mastering Internet of Things

The book “Mastering Internet of Things” by Peter Waher describes many of the above technologies and communication patterns. You can find the book on Packt, Amazon, Bokus and other stores.

Example projects

Many example projects are available on GitHub in the Mastering Internet of Things repository. References to examples, client libraries and software are also available in the Neuro-Foundation XMPP IoT Interfaces repository.

The IoT Gateway

The IoT Gateway repository contains software, libraries and examples for integrating with the IoT Broker.

Contact

If you have any questions or comments, if you would like to request added features, or if you would like to license the software, please go to the Feedback page. If you want to try the IoT Broker, you can Request an account. If you want to automate account creation, you can Request an API key. Account creation on this broker requires a valid API key.