Hacker News Reader

Comment by adamcharnock | Hacker News Reader

This is precisely the problem I’m having right now. I’m working on the server side of an IoT project and trying to figure out a tenable way to secure an MQTT connection on devices with somewhere between 4-32kb of RAM. If anyone has any suggestions I’d love to hear it.

View on HN

Based on my experience on releasing a secure IoT device on a microcontroller: You will need to spend a lot of time optimizing that. The most used TLS library (mbedTls) requires 20kB send and receive buffers for each connection. That doesn't involve buffers for the TCP/IP stack yet, and also not anything for an application. You can reduce the buffer sizes, but then you are no longer standard compliant (at least on the receiving side) and if the server sends longer TLS frames the device might close the connection or exhibit undefined behavior.

You can either experiment with other TLS libraries or investigate whether a more powerful device wouldn't make your life easier.

The ace working group within the IETF has a fairly recent draft[1] standard on this.

[1]: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-pro...

Thank you for this, I’ve just taken an initial look. I had understood that TLS would be a no-go in such a constrained environment, but perhaps I am mistaken.

Public key crypto (required for SSL/TLS) is difficult to fit in that RAM footprint. You don't have enough RAM to hold an RSA or DSA key, let alone a certificate chain!

Usually devices of that size will use a dedicated crypto chip to store and manipulate the keys.

Elliptic curve algorithms fit better into that RAM footprint, if you can afford to sacrifice protocol compatibility.

If you can drop the SSL/TLS requirement and fall back to authenticating and encrypting your payloads over HTTP, RC5/SHA might suffice. Hash some unique serial number on your device and use that as a key. Auth is provided with a secret key burned into your device -- but this opens up big risks if your physical device or its firmware are compromised.

Sorry, but TLS has PSK cyphers that do not use asymmetric cryptography. They are not used often, as you normally want the benefits of asymmetric cryptography, but they are useful if you can pair devices out-of-band and can store a unique secret key for each communication partner.

You're not going to have much RAM left after running a TCP/IP stack and the layers below it -- are these actually IP devices, or do you have a gateway?

(Perhaps consider https://teserakt.io/ for the securing-MQTT part.)

Is there really no estabilished open-source solution to this problem? It seems very sad since rolling your own crypto protocol even from knwon good primitives is such an infamous minefield.

Also apparently many "IoT" labeled devices are not actually on the internet, but are using some kindof gateway to the net. In this case you would lose end-to-end security by just using TLS to the gateway.

If you can share a secret then some hmac + e.g. aes128 will make communication virtually impenetrable and protected aganst all or almost all possible attacks. aes needed for hiding data inside, hmac for data integrity (protection against resending etc). If you don't have any crypto built into hardware it will be tough

Consider PSK TLS. I.e., fixed AES key and something like GCM or similar for integrity. No certificates. Libraries exist, also it's a lot faster on both ends to handle than RSA crypto.

If you didn't need many features, you could theoretically wrap mqtt in dnscurve payloads; lighter weight than tls and still very secure.

Look at something like wolfmqtt or equivalent - this is like 3-4kb, if you are targeting mqtt.

Reply on news.ycombinator.com