3

For IoT devices with limited resources (e.g. embedded system with 32 kB RAM, 128 kB Flash memory, running an RTOS such as FreeRTOS, small TCP/IP stack such as lwIP):

It might be useful to have a terminal type protocol for debugging or testing. However, telnet is not secure, while SSH seems sufficiently complicated so that it's difficult to implement and fit into such a small system.

Are there any lightweight yet secure terminal protocols that are suitable for such a resource constrained IoT system?

Pragmatically, is it possible to cut down SSH to a lean implementation, e.g. with AES but no 3DES, even though the latter is technically mandatory for a conformant SSH implementation?

9
  • I did find this: NIST Developing IoT Security Standards for Small Electronics Commented Sep 6, 2018 at 1:44
  • Does the implementation need to be open source?
    – forest
    Commented Sep 6, 2018 at 2:57
  • @forest Ideally it would be a well-enough established protocol so that there is some open source participation. But I'm willing to consider anything. Commented Sep 6, 2018 at 6:22
  • Is it the protocol or the implementation you are looking for? Because there are plenty of extremely simple protocols for encryption and authentication, but which one is ideal depends entirely on your threat model. If you don't need authentication for example, you can just use RSA with PKCS#1 for key exchange, AES in CTR mode for encryption, and HMAC-SHA1 for integrity. But that would not prove identity (or prevent reflection attacks, unless you use a different key for each direction). It would, however, be extremely lightweight (even more so if you use something simpler than AES).
    – forest
    Commented Sep 6, 2018 at 6:28
  • @forest Either or both. My first question is about a protocol, and given a protocol, an implementation would be very helpful. My second question is about the possibility of a small SSH implementation. Commented Sep 6, 2018 at 6:40

1 Answer 1

3

If you only need this for testing and debugging, why do you need it to be secure? You should not be debugging live systems while they are in a potentially hostile environment where a secure protocol would be needed. Considering the fact that even the very lightest secure protocol would eat up a significant portion of system memory, it would be silly to allocate such a high amount of resources for just debugging and testing. What you should do instead is only test your devices when you have physical control over them, ideally over a physical network link.


32 kB of RAM is really pushing it. Even Dropbear cannot run on a system that limited. Even doing TLS will be difficult, as WolfSSL may barely fit. The WolfSSL SSH library requires a minimum of 33 kB. It's likely that you'll need to develop this yourself, which should not be too difficult if you are using FreeRTOS. There is likely nothing that you can simply drop in to a 32 kB system.

If you are using Contiki as an RTOS, you may be able to use this TLS/DTLS implementation. It requires slightly more memory than 32 kB, but you should be able to strip it down sufficiently if you are familiar with embedded programming and optimization and don't need all the features.

When you begin to use systems this constrained, each individual system will have different priorities. As a result, no one creates a one-size-fits-all library for something as complicated as a secure remote access protocol. You are generally expected to be able to implement it yourself to fit your exact needs, either from scratch or by forking an extremely lightweight library. If you are not likely able to do this, you may have to rethink either your hardware and switch to something other than FreeRTOS, or your threat model (and communicate with the system over a secure medium).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .