The goal of my development efforts has been the implementation of an IoT framework for embedded devices that requires no connection to the cloud. I want a framework that I can use within my firewall that does not need to connect anywhere. I can then allow only the data I want to make it to the cloud. This makes security a little tricky for me. I intend to use web interfaces to access the devices, but I still want to ensure secure access to the device. I will be targeting Google Chrome as the web browser
Stack overflow has several discussions on the topic of securing devices on an internal network.
This one is pretty good ->
https://security.stackexchange.com/questions/121163/how-do-i-run-proper-https-on-an-internal-network
When it comes down to it there are only two ways to proceed:
- Self signed certificates
- Public certificates for internal addresses
The stack overflow discussion mentioned previously can give a overview of some of the options.
For this project’s needs option 2 is not attractive because the need to involve an outside entity for certificate management. Option 2 also requires a more advanced approach to network routing and a hard requirement for at least occasional internet access for certificate validation. It has the benefit of effortless compatibility with web browsers.
Self signed certificates can provide a complete disconnect from outside entities if desired and still allow for web interfaces on the IoT devices. The downside is that the self generated root certificate will need to be installed on every device that is used to access the systems via SSL. Steps to do so on each O/S varies but is just a Google search away.
There is an excellent writeup here on how to generate self signed certificates. The focus is for local software development, but the result generates certificates that will meet the projects needs.
There are two things to keep in mind here. First: server SSL certificates can only have a life span of 2 years. Trying to generate one with a longer life will succeed but Chrome will reject it. Secondly — the root certificate will need to be imported in each O/S that will be used to access the IoT device. This is actually kind of a benefit as we an control release of the root certificate authority according to our security situation.
Instructions to create a trusted certificate:
https://github.com/dakshshah96/local-cert-generator/
When I set up my certificates I gave the root a lifetime of 20 years. I don’t want to have to touch a machine more than once. The server certificates had to be set to 2. The certs can be used for the Mosquitto server as well. This site has a good explanation of how to set up a Mosquitto server for SSL
Managing users:
Each O/S has a specific way this must be done.
Mac O/S:
The original article details how to import the root certificate into the Mac keychain.
Windows/Linux:
This article details the steps: How to import CA root certificates on Linux and Windows. The Windows instructions worked without issue. The Linux instructions are iffy.
I0S:
The root ca must be emailed to an IOS device and imported. This article details the steps –> https://medium.com/collaborne-engineering/self-signed-certificates-in-ios-apps-ff489bf8b96e . These instructions had no issues.
Android:
This site has instructions on how to install self signed certificates. The steps were not tested.
Useful links:
Enable SSH for PAHO JavaScript client:
https://stackoverflow.com/questions/53051679/how-can-i-use-tls-with-paho-mqtt-over-javascript. The PAHO client will not use client certificates (which are the same as the sever certificates) and will support SSL only rather than full encryption. To do this in a browser mqtt.js will need to be used.
Securing raspberry pi:
https://www.raspberrypi.org/documentation/configuration/security.md
m2ag.labs 