5 ms·

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 co

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.

becauseiam 7y ago
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-profile/ https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-pro...
- adamcharnock 7y ago
  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.
out_of_protocol 7y ago
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
ctz 7y ago
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/ https://teserakt.io/ for the securing-MQTT part.)
spydum 7y ago
Look at something like wolfmqtt or equivalent - this is like 3-4kb, if you are targeting mqtt.
peterwwillis 7y ago
If you didn't need many features, you could theoretically wrap mqtt in dnscurve payloads; lighter weight than tls and still very secure.
ianhowson 7y ago
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.
- namibj 7y ago
  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.
Matthias247 7y ago
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.
namibj 7y ago
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.
fulafel 7y ago
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.

becauseiam 7y ago

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-profile/ https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-pro...

adamcharnock 7y ago
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.

out_of_protocol 7y ago

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

ctz 7y ago

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/ https://teserakt.io/ for the securing-MQTT part.)

spydum 7y ago

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

peterwwillis 7y ago

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

ianhowson 7y ago

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.

namibj 7y ago
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.

Matthias247 7y ago

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.

namibj 7y ago

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.

fulafel 7y ago

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.