Fight Industrial Data Security Breaks with Secure Enterprise MQTT Broker

Fight Industrial Data Security Breaks with Secure Enterprise MQTT Broker

We all know that our world is more connected. Billions of intelligent tools and machines are generating enormous amounts of data, which creates enormous potential for businesses and other organizations to optimize their operations and achieve efficiency. As IoT devices continue to evolve, every newly connected product is vulnerable to hackers, and security turns into a significant concern. Fighting the industrial data security breaks is a 100% mandate to protect critical data in any place it dwells. Bevywise MQTTRoute provides an option to enable encrypted data transmission for better MQTT data security. It works with all standard SSL / TLS certificates and runs with a self-signed certificate. This article provides complete guidance on securing the delicate data that you transfer over the Enterprise MQTT Broker.

MQTT Broker Security Fundamentals

With regards to security in Enterprise MQTT Broker, there are some fundamental concepts to take into account they are identity, authentication, authorization, and encryption. In this tutorial, we take a gander at how you can confine access to a broker, and protect your data using different security systems.


Every client has a unique Client ID. The Enterprise MQTT broker indicates that the client must report the client ID when requesting a connection. When the broker receives a connect command from the client, it determines whether to allow the client to connect only if the received message contains a legitimate client ID, user name, and password. The client can use UUID, mac address of the network device, or other unique client information as the client ID.

Authentication With X.509

This is the safest method for client authentication. In addition to authentication with username and password, the MQTT broker allows a device to authenticate with an X.509 certificate. This certificate provides authentication at the transport level. X.509 uses a public key infrastructure to verify that a public key belongs to a client. In the X.509, a certificate authority is introduced to verify the identity of a client. During the handshake process, the client presents the broker with its certificate, which contains information such as identity and public key. Then the broker relays this certificate to the certificate authority for verification. After verifying the client certificate, the broker ensures it is genuine or not and gain trust in the binding with the client name and public key.

Client Authentication

There are three ways to verify the identity of the MQTT client on Bevywise MQTT broker : the Client IDs, Usernames and Passwords, and the Client Certificates.

Client ids

All MQTT clients must provide a client id. When a client subscribes to a topic the client id links the topic to the client and the TCP connection. With constant connections, the broker remembers client IDs and subscribed topics. When configuring the MQTT client you need to relegate the Name / ID to the client. However the Bevywise MQTT Broker allows you to impose client id prefix restrictions on the client name, and this provides some basic client security. You will find this setting in the security settings section of the broker.conf file.

########### prefix for Random Clientid Generation ###########

Username and Password

An Enterprise MQTT broker can request a valid username and password from a client before allowing a connection. The username and password combination is transmitted in plain text and is not secure without some form of transport encryption. However, it does provide an easy way of restricting access to a broker and is probably the most common form of identification used. The username used for authentication can also be used in restricting access to topics. On the Bevywise MQTT broker, you need to configure settings for this to work. Again you will find these settings in the security section of the broker.conf file. The devices can connect using MQTT Username / Password or you can connect it without the username and password. You have to change NO to YES if you are planning to use Authentication.

################ Device Authentication #################
# YES || NO

To create the passwords you will need to use the utility that comes with the broker. You can add the Username and passwords on the UI under the Security tab for secure client connections.


Authorization is managing the clients’ rights. The most common types of authorization used are Role-Based Access Controls (RBAC) and Access Control List (ACL). RBAC provides a level of abstraction between the client and the main resources. It facilitates the administration of security in a large organization. This allows the broker to authorize the clients published or subscribed topic. ACL associates certain clients with a list of permissions that includes who can access the resources and which operations are allowed. ACL provides policies on what topics a client can subscribe / publish. Using ACL or RBAC, the broker implements topic permissions to restrict a client from publish / subscribe to unauthorized topics. Each topic permission allows the broker to specify authorization for clients and limit them to subscribe and publish messages. If a client attempts to perform an unauthorized operation, the broker can perform actions such as disconnect the client by preventing it from publishing data to other clients.

Authorization with Access Tokens

Another approach to providing authorization is a token authorization. Token authorization permits a client to request the scope or privileges that the client has. To connect to the broker with an access token, the client must use the password field to send the access token with the connect message. The client must be given an access token before requesting a connection. There are a variety of token services available. The most commonly used are OAuth and OAuth 2.0.


It is a token-based authentication that is used to provide SSO and permits information to be utilized by third party services. It likewise requires an identity provider for authenticating clients’ access.

OAuth 2.0

It authorizes third-party applications to access the client account and authenticates the client by following the authorization code flow.

Securing Data

There are numerous possibilities to hack the data transfer between Clients and Broker. To protect the contents of your MQTT messages, you can use TLS or SSL Security and Payload encryption. Enterprise MQTT Broker eliminates “Man in Middle attack” by enabling data transfer through TLS port.

TLS / SSL Security

TLS / SSL security is a more commonly known security used on the web. This security is part of the TCP / IP protocol. TLS provides a secure communication channel between the client and the server. TLS certificate is provided for both server and client, and those certificates will be verified and authenticated by Certificate Authority before connection. The broker will connect only if the Certificate and host IP match.

Communication between clients and the server must be ensured by enabling TLS mode and setting passwords for the connection. You can use a single password for all clients or individual passwords for each client. Open conf/ folder on broker.conf and update TLS_ENABLED to TRUE . All other values can be changed if necessary. Using a non-regular port number for Broker and a secure web socket will further enhance security against DDOS.

#########MQTT BROKER CONFIG#######
PORT_NO = 8883
WS_PORT_NO = 10443
# TLS_PORT must be 88xx.
TLS_PORT_NO = 8883
WSS_PORT_NO = 11443

Payload Encryption

This is done at the application level and not by the broker. You can encrypt data without configuring the broker. It likewise implies that data is eventually encrypted and not just between the broker and the client. However, this type of encryption doesn’t protect passwords on the connection itself. Because it doesn’t involve any broker configuration or support this is likely to be a very popular method of protecting data.

WILL and Retained message

Last WILL, will help the subscribers to know when the publishing device has gone down or got disconnected from the broker. Retain tag tells the broker to keep the last published message for the new subscribers to know the last published messages while connecting for the first time. Besides, the Enterprise MQTT Broker provides both these messages as needed for the realtime.

DataBase Storage

The broker will store the data into the database for further analysis and decision making. The default DB supported is SQLite. But the DB Configuration can be modified to make it work with MySQL or any other Big Data engine. Please refer to the help document to set up MySQL, its dependency packages, and other big data engines.

Intuitive User Interface

Through a web-based primitive User Interface broker, you can view the active devices and recent activities of different devices. It also helps to view the activities and messages sent from and to specific devices.

Get your free version of MQTT Broker now for secure data transfer.

download now

The product page and the help documentation will provide more information on configuring and running the Broker securely. For more queries, feel free to contact us at [email protected].

Secure MQTT Broker hosting on AWS

Secure MQTT Broker hosting on AWS

Internet of things is all about mobility and managing your devices and sensors from anywhere in the world. Hosting a secure MQTT Broker  on the cloud is a mandate to achieve this. But people are very much paranoid about the security of the application and the data. This article provides a complete end to end guide for hosting a secure MQTT Broker on AWS . The message broker used for hosting MQTT Broker AWS is Bevywise MQTTRoute.

Create an AWS Account

Create a FREE AWS account which you can use for a year. You can check the details of the FREE tier here. Besides that, the AWS account provides a single CPU with a 1 GB of RAM, 5 GB of storage space and more. This is a very good configuration to run the MQTT Broker on the VM.

Preparing EC2

Create an EC2 instance and If you are particular about the FREE usage, make sure you choose the allowed VM type. However, For the Operating System, choose an Ubuntu 14.04 or 16.04 instance.

Create an SSH Key Pair for using for connecting to the EC2 instance via SFTP and SSH. But, If you already have an SSH key you can use the same. The key will be in the name of Yourname.pem

The VM provided will be a plain vanilla version of the Ubuntu. Then you can connect to the EC2 instance via SSH. After that Update the Ubuntu for any patches and install zip utility.

$ sudo apt-get update
$ sudo apt-get install zip unzip

Setup MySQL

The secure MQTT Broker uses MySQL to store the connected clients, their subscriptions, and the message transactions. Install the MySQL using the following commands. Then These commands will ask for your root password and also make your MySQL instance secured in the EC2 Instance.  But, Remember the MySQL password which you need to configure inside the MQTT Broker configuration files.

$ sudo apt-get install mysql-server
$ sudo mysql_secure_installation
$ sudo mysql_install_db

 Make sure the  MySQL is set to run in the localhost (  Then Check the /etc/mysql/my.cnf

bind-address =

The Ubuntu is now ready to run the broker.

Set up Secure MQTT Broker

Download the FREE MQTT Broker here.

download now

You can copy the files to the EC2 instance using SFTP using tools like FileZilla.  Besides that You can use the same SSH key  to pair for the authentication purpose. Let us start installing the MQTT Broker in the EC2 Instance.

Unzip the MQTT Broker and move to the product home folder.

$ unzip
$ cd Bevywise/MQTTRoute/

Configure MySQL parameters inside the conf/db.conf.

Change the default DB server from SQLITE to MYSQL and update the MySQL password which you provided during the installation of MySQL.



Securing Client Connections

 Enable the TLS mode to secure the communication between the clients and the server and setting up passwords logging in.  Then You can use a single password for all the clients or individual passwords for each client.

Open the conf/broker.conf and update the TLS_ENABLED as TRUE. However You can change all other values if needed. Using a non-regular port number for Broker and secure web socket will further enhance the security against DDOS.

TLS_PORT_NO = 8883
WSS_PORT_NO = 8000>

Create a strong set of username and passwords which can be used when the clients connect to the secure MQTT Broker.  Besides that You can add your list of credentials inside Certificate/Authentication/ folder.

The username and password must be
operation_mgr_usr [email protected]
external_dev_user [email protected]!*&Rs4

Then Enable authentication in the conf/broker.conf.  However If you wish to use a different file for the username and password list, you can change the path of the credentials file.

# YES || NO
PASSWD_FILE = ./Certificate/Authentication/credentials.txt

Then Start the MQTT Broker in the background to make sure the broker is running continuously.

$ cd ./bin
$ nohup sh &

The MQTT Broker will start on the TCP port 1883, Web Socket port 8000, and HTTP port 8080.

Securing User Interface with Apache

The apache server will be set as the front end for the User interface and the request will be routed to the port 8080 of the MQTT Broker using the virtual host configuration of the apache. After that, The basic authentication of the apache will be enabled for the securing the User Interface.

Install the apache server.

$ sudo apt-get install apache2
$ sudo apt-get install apache2-utils

Firstly The Username and the passwords need to be added to the apache for enabling the basic authentication. then To add the user name, run the following command. Finally This will ask for the password and confirmation and it will be added to the .htpasswd file.

$ sudo htpasswd -c /etc/apache2/.htpasswd <<User_name>>

Confirm the user addition by using the following command

$ cat /etc/apache2/.htpasswd

Finally You need to restart the apache server for the authentication to be enabled. Let us do the proxying to the port 8080 before restarting the server.

Enabling the Proxy modules of the apache.

$ sudo a2enmod proxy
$ sudo a2enmod proxy_http

 Then for reverse proxy, we need to add the following into the /etc/apache2/sites-enabled/000-default.conf.

ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/

<Location “/”>
AuthType Basic
AuthName “Restricted Content”
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Restart the apache server for the above changes to take effect.

$ sudo service apache2 restart

Configuring AWS Firewall

The AWS firewall can be configured using the Network & Security → Security Group option inside the AWS Console. Then You have to enable inbound connection to only 4 ports, Apache — 80, Web socket — 8443, TLS TCP — 8883 & SSH — 22. However If you are planning to connect devices only from your internal network, you can use the option of My IP for the Source to make sure AWS restricts all the other IPs from sending data to this particular port making it more secure.

Mobile Application

We do have a basic mobile application which can be used to send and receive MQTT Messages to and from the different devices. We are yet to host them on the App Store and play store. But we can send you the same.

If you are using a FREE version of the MQTT Broker, you will be able to connect up to 25 clients to the broker. In addition You are using a completely FREE MQTT Server on the cloud with all the basic needs.

Finally The MQTT Broker is available for more devices at a very affordable price.

However, If you are looking to connect millions of devices, we do a have highly scalable distributed micro services based IOT Platform which is being integrated into powerful data visualization. Hence The Platform can be extended and customised based on the vertical and its objectives.

Similarly Enable your devices for a powerful M2M communication by setting up a FREE private cloud based secure MQTT Broker. We would be happy to hear your success stories on the setup process.

If you need any assistance on enabling IoT into your current process, we could help you get it done using our platform and the smart SDK. Feel free to keep us posted via the contact us form.

5 reasons "Why we choose MQTT"

5 reasons "Why we choose MQTT"

IoT network finds application in day-to-day essentials from Home appliances, Public safety, Farming and Hospitals to high precision jobs including Smart cities, Automobiles, Industrial Automations and Satellite tracking.  After analysing the available protocols, we decided to go with the MQTT protocol (MQ Telemetry Transport) for our communication system.

Bevywise Networks was started with the aim to create IoT devices, sensors and softwares as mobile applications. Professionals and regular persons can use this around the world to automate and simplify their social, business and personal needs.

So We wanted our devices to communicate in a secure and reliable way.  Hence We believe “Quality & Reliability is no more a luxury, It should be something built inside”.

Here are the 5 things about MQTT protocol which made us to choose it for our IoT implementation.

1. Security

Even though MQTT messaging uses an unsecured TCP, we can be able to encrypt data with TLS/SSL Internet security to make it robust, when implementing for the mission critical business. So that We can have partial and complete encryption based on the resourcefulness of the system and security mandate.

2. Central Broker

We may be getting billions of devices on the Internet over the next 5 to 10 years. Broker which can act as a server can effectively reduce the number of packets that fall into the internet and also the amount of processing the individual memory needed for the clients. We should be able to build a grid of highly interoperable brokers across different vendors.

3. MQTT protocol – QoS

MQTT defines three QoS which can cater to based on the importance of each messages and the repetitiveness of the messages in the environment.

At Most Once – Client configured with QoS level 0 will publish messages only once. This is just a confirmation message and the receiver client  will not  store or respond to it.

At least Once – Client configured with QoS level 1 will publish messages more than once. This message will be stored by the sender until a confirmation message is received from the other Client.

Exactly Once – Client configured with QoS level 2 ensures publishing the message exactly once. This is the most secure level of publishing messages.

4. Last WILL & Retained Message

Last WILL helps in knowing whether the particular client is available or not. It is not worth waiting for something that won’t happen. The listeners can be put on the power saver mode with interval based wake up to check the publisher availability.

Retained messages will help subscribers receive messages that were published some time before.

These messages highly decouple both the publisher and the subscriber to work independent of each device.

5. Flexible Subscription pattern

A Particular client can subscribe to all the topics published based on a pattern. For example, a smaller monitor for kitchen can listen to all topics on kitchen by subscribing to

Topic Name: home/kitchen/+’+’ represents various sensors in kitchen (eg. ‘+’ can be temperature sensor, motion detect sensor, etc.)

In a similar fashion, a client can subscribe to all the temperature level of the house.

Topic Name: home/+/room_temp’+’ represents various rooms with temperature sensor (eg. ‘+’ can be Bedroom, Hall, Kitchen etc.)

Not only these, there are many features of MQTT which benefits us. We have released the beta version of the IoT simulator for the MQTT Protocol. Please download and give it a try and visit our documentation to know more.