The availability of cheap WiFi boards like the ESP8266 and others means you can inexpensively put projects on the network. But there is still the problem of how to connect these devices to other places reliably. An Open Source project that attempts to make that whole effort point and click is Mongoose OS. The open source system works with the ESP8266, ESP32, and several other platforms. It is well integrated with Amazon’s IoT backend, but it isn’t locked to it.
Everyone wants to be your IoT broker and we see products appear (and disappear) regularly aimed at capturing that market. One common way to send and receive messages from a tiny device to a remote server is MQTT, an ISO standard made with resource-limited devices in mind. Many IoT services speak this protocol, including Amazon’s IoT offering. You can see how quick it is to flash an ESP8266 to make an Amazon IoT button in the video below. Although the video example uses Amazon, you can configure the system to talk to any public or private MQTT broker.
Calling Mongoose an OS might be a bit of a stretch. It is really closer to what we think of as “middleware” but it does provide many networking and filesystem services. It also simplifies remote deployment with a lot of support for doing safe over the air updates to devices. It looks like they’ve done a lot of work to help secure devices, too.
If you need a real OS, Mongoose can sit with an actual RTOS, like FreeRTOS for example. You can code in C or JavaScript and — as you’ll see in the video — you may not even need too much of that if you can leverage one of the built-in examples. Overall, it looks very productive.
MQTT is pretty simple, so you don’t actually need any support to use it. However, Mongoose brings a lot of other things to the table such as security and updates, plus portability. If you want to compare and contrast, the MQTT wireless doorbell project is pretty similar. And remember, if you want to merge the two, that Mongoose OS could just have easily sent the message to your local Raspberry Pi as off to Amazon’s servers.
So, we crab about insecure IOT devices and yell about how stupid product developers are for not insisting on security and here’s an IOT device without TLS? How’s that in any way professional?
“The S in IoT stands for security”
Where does it say that? I haven’t dug into the security part but according to their web site:
Filesystem encryption for device data protection
Using trusted mbedTLS library for encryption and mutual TLS authentication
TLS footprint tuning: RAM usage reduced from 32k to 2k per connection
TLS adoption for ATECC508A crypto chip for protection against unathorized (sic) cloud access
Secure boot & full flash encryption on ESP32
I think Truth was making a joke. There is no S in IoT. Next thing you know someone is going to mention that there is no spoon either.
I was referring to the one to come after, the IoTs or maybe even Incredibly Dangerous Internet Of Things (IdIoT for short).
Ooh! I’m stealing that acronym.
ACRONYM, Abbreviated Coded Rendition Of Nomenclature Yielding Meaning
Amazon AWS IoT requires mutual TLS to connect. That means that the device shown in an example talks MQTT over TLS, and there is no other way with AWS IoT.
The other question is about securing the credential on flash, there is an answer to that too: crypto chips, https://mongoose-os.com/blog/mongoose-esp8266-atecc508-aws/ .
I see!!!
These folks spent the time to add an Atmel ATECC508A to the ESP8266 so that they can do REAL TLS!!
I say congratulations to the MongooseOS people. Nice job. I will certainly check this out myself.
(Also, it is possible to squeeze WolfSSL to run on an ESP8266 and connect to Amazon IoT securely without the ATECC508A, but there’s just no room left for the fun stuff.)
actually… we kinda did. we reduced mbedTLS (nee WolfSSL) footprint, so there’s quite a bit of room left for the fun stuff. with Mongoose OS, ECC certs and software crypto (no chip) peak ram usage during handshake is about 16K and you get about 20K RAM left for the fun stuff.
and with chip, peak usage during handshake is about 10K and about 26K minimum ram free (savings come from skipping a bunch of bignum computations).
Since you’re here, do you support OCSP or another form of CRL and date-checking the cert from the server?
Those two took us up over the threshold of acceptable RAM usage. Still runs, but it real tight.
Also, getting the time and date for certificate checking. Sheesh. Do you use NTP before starting up the TLS connection?
Real nice job here. Thanks.
(reply to Alan’s comment)
at the moment we don’t do either. date checks are coming soon, the plan is yes, to do NTP on power-up (unless RTC is running).
there are no current plans to enable CRL checks.
“Everyone wants to be your IoT broker…”
Translation: “Everyone wants to SPY ON YOU…”
Actual translation: everyone wants to take the things you’d otherwise own and rent them to you, while also making side money on selling your data.