Security is one of the major concerns of the IoT Manager applications. Keeping this in mind, we built the manager applications with different level of security. IoT Network Simulator is enhanced to support all manager applications based on their security practices. Similar to the previous version, the simulator supports all its options from the user interface itself.
The User interface will provide options based on the IoT applications. For example Azure IoT hub supports SAS Token and Certificate based authentication. Users will be able to create a specific network for the Azure IoT core and able to create devices that handshakes with the IoT hub based on the details specified when configuring the device. Similarly, this is possible for the AWS IOT as well.
Simulating IoT Network for Other Manager applications
For all other manager applications like Bevywise IoT Platform, Losant , and others, you will be able to specify a single certificate at the common settings page and get your devices connected to the manager application.
Device level SSL Security
Azure IoT / AWS IoT manages every device to have an unique certificate. In addition, IoT Network simulator supports configuration of the root Certificate in the settings window and ensures that you specify each and every client certificate in the device configuration screen. The WILL , QoS , retain , event messages and command messages configuration are the same as before.
Individual Device IP Address
Simulator runs on a single machine and simulates all its devices. But, The manager will be seeing all the devices from one Host (IP Address). This contradicts the realtime Simulation. In order to overcome this, the 2.0 version has added support for using Virtual IP Address. By this functionality, each simulated device will connect to the manager application from different host Address.
MQTT Security is one of the most important mandate of the connected devices today. Hence We want to make sure our customers are able to make sure their devices, their connections and the data sent over for communication are secured. Already we support SSL / TLS data encryption for data security and we can enable strict mode where each client should have a unique certificate or a flexible mode where in all your clients can have the same certificate.
In addition We have recently added support for configuring multiple username and passwords in the
MQTT Broker. Previously it was allowed to have only one username and password for all the devices of the MQTT Broker.
Configuring MQTT Security – Authentication
You can configure the list of username and password in a file in the format,
UserName <TAB> Password
and then specify the file path in the /conf/broker.conf file
SSL Certificates plays a major role in enabling the security. Hence, MQTTRoute provides an option to enable SSL / TLS mode of encrypted data transfer for enhanced MQTT Data Security or secure MQTT Communication. Works with all standard SSL/TLS Certificate or run with self signed certificate.
SSL certificates are files that has digital data of encryption key to encrypt data for security. Hence, You can use the certificates to make sure the data encryption in the tunnel and cannot be tampered. There is a need of key for decoding the data at the other end.
This blog provides a detailed and a quick guide to create a self signed certificate using the openssl installed in ubuntu.
Create Root Certificate
The following command creates the private key file.
openssl genrsa -out root.key 2048
To create a password protected key by adding -des3.
openssl genrsa -des3 -out root.key 2048
The above command will create a root.key In the current folder. our next step is to generate Certificate signing request file using above generated RSA private Key. Besides that, It contains encrypted personal details of the Host ie. country, state, organization, common Name, email address, and public key.
openssl req -new -key root.key -out root.csr
The above command will prompt for the following details.
Country Name : State or Province Name : Locality Name : Organization Name : Organizational Unit Name : Common Name (e.g. server FQDN or YOUR name): Email Address : A challenge password :(optional) An optional company name :(optional)
You can use the above two files to sign the certificate.
The above procedure followed for the server certificate can be used to create the client certificates. Please use appropriate name for the files.
The above certificates are also valid for 365 days. Same Certificate Authority is used for generating both the client and Server certificate.
Secure MQTT Communication in MQTT Broker
The root certificate, server certificate and server private key needs to be placed on the server side and the root certificate, client certificate and the client private key needs to be placed in the client side.
We can either have a common client certificate or individual certificate for each client. You can issue a certificate to client using your own root.key and root.crt. MqttRoute / MQTT Server verify the common name and the client IP during the connection process. If both are same then only broker allows the client to connect otherwise reject the client’s connection request.
Follow the steps to run the MQTT Broker and the MQTT client in the MQTT Broker.
Broker certificate and Key file MUST be present in ./Certificate/server folder.
Client certificate and Key file MUST be present in ./Certificate/client folder.
CA Certificate MUST present in ./Certificate/root folder.
Broker and Client certificates MUST be signed by same CA.
Download the makefile and follow the above procedure to secure MQTT communication in minutes. Please make sure the necessary information is provided during the prompt.
MQTTRoute is designed to secure the data from the device to enterprise system. Learn more about the data security for secure MQTT Communication. You can download the FREE MQTT Broker now.
Write to support for any assistance regarding MQTT Security.