ESP32 and security

Question

I'm wondering how secured an ESP32 is.

I'd like to use one to read data on a Telnet device which should remain in an offline network for security purposes.

• The ESP32 uses an Ethernet connection to this device and periodically sends Telnet commands and reads answers.
• Once an answer is received, the ESP32 broadcasts an MQTT message over WiFi (or a second Ethernet port, haven't decided yet) that can be handled by a supervision computer to display charts and gauges.

                             ┌───────────────────────────────────────────┐
                             │Secured network                            │
                             │                                           │
    ┌───────────┐            │  ┌───────────┐    REQ      ┌───────────┐  │
    │Supervision│    EMIT    │  │           ├────────────►│ Protected │  │
    │ computer  │◄───────────┼──┤   ESP32   │             │  Telnet   │  │
    │           │    MQTT    │  │           │◄────────────┤  Device   │  │
    └───────────┘            │  └───────────┘    ANS      └───────────┘  │
                             │                                           │
                             └───────────────────────────────────────────┘

Is an ESP32 100% secured once the code has been uploaded to the device? Couldn't a hacker use the WiFi/Ethernet connection to change the code?

Answer 1

See also Marcus Müller's answer for important additional views

Telnet is of course not secure at all, in that it provides no encryption or other security features; it appears your design is intended to add security to an existing telnet-only device. Of itself, this is a good plan: you're physically preventing telnet access to the weak device, and a well-programmed microcontroller is a lot harder to hack than a general-purpose computer.

If you're concerned about security, always choose wired over wireless connections. It is so much easier to control. A factor often overlooked is that wifi security is based on encryption, and encryption tends to weaken over time against the rising power of CPUs. Embedded devices are especially susceptible to this, as they very frequently are in service for ten years or more and usually receive no maintenance. Consider also emitting syslog (or similar) messages just to keep track of what it's up to. Consider whether this system is weak against rogue DHCP, rogue ARP, rogue NTP etc. Consider using broadcast UDP for everything: you can organise it so there are no incoming packets whatsoever (not even ARP), and no configuration, so you can switch off all packet reception entirely.

To prevent reprogramming of your ESP32, use the write-protect fuse bits. Even if someone got access to reprogram it, they can't. Also, consider the read-protection fuses, which prevent the device from being read: this really helps prevent others from finding vulnerabilities. As far as I know, all microcontrollers have these features.

See ESP32 fuse documentation.

When thinking about security, try to avoid ideas like "100% secured", as there is no such thing. Instead, consider "how much resource would it take to break it to the extent of X", where X is deny service, elevate permission, reprogram, etc, depending on your concerns. If it requires the resources of the CIA and takes a year is very different from requires 1000 CPU-hours and an undergraduate crew.

Lastly, think about surprise failure modes of embedded devices. I have had devices from major manufacturers (for example protocol converters, PLCs) which had very surprising flaws: one would forget its parameters if the power was removed in a particular 50 ms window several seconds after power-up; others have had "beginner" buffer-overrun bugs; others have had very-hard-to-find incompatibilities in the TCP stack. In general terms, for security, use the simplest possible device you can in a way which is difficult to manipulate.

Answer 2

I'm kind of the opposite opinion of Jonathanjo

If you're concerned about security, always choose a modern, well-established encryption method; the medium doesn't matter, and wired is the easiest to sniff and intercept. Jonathanjo's statement that ciphers do get easier to crack over time with growing compute power (ASICs, FPGAs, and GPUs: we're not cracking encryption with CPUs anymore, too slow) is right, but irrelevant: for anything made of the semiconductors we know today, we won't be cracking AES-256 to get access to a microcontroller. That's just such a stupid attack scenario: in order to passively read a recorded session, you'd spend millions to tens of thousands in electricity, even if we had the machines fast enough to do that (we don't.)? And in the meantime, the key got rotated as mandated by modern WPA, so you can't even send fake data? I doubt that whatever you're building is that lucrative.

If you want operational safety in absence of physical tampering, use wired. You can jam wireless from the next room. You can also jam wired electronics, but it takes orders of more power.

Jonathanjo is absolute, 100%, on point:

When thinking about security, try to avoid ideas like "100% secured", as there is no such thing.

yep. Think about ancient fortresses / castles: safe against specific attacks, not safe against others, only safe in context with monitoring (say, people with arrows, rams and swords will not throw down a 2m thick stone wall, but enough people with arrows covering other people with ladders is another problem).

Instead, consider "how much resource would it take to break it to the extent of X", where X is deny service, elevate permission, reprogram, etc, depending on your concerns. If it requires the resources of the CIA and takes a year is very different from requires 1000 CPU-hours and an undergraduate crew.

Threat modelling is the engineering discipline of having an idea of 1. what you protect, 2. against which kind of adversary, 3. using which kind of resources, 4. to which end. Start with that! Piece of paper, pencil, write down the answer to these 4 questions first. Research if you can't answer them right away.

I think the main risk here is that re: 1. you're defending a device running someone else's software stack. Microcontroller firmware on average is not as good as it should be. ESP's IDF isn't the worst, but you can't look inside the firmware blob actually doing Wifi. I'm sure your MQTT library is written and tested; but you need to make sure it's really not doing things on a microntroller that it wouldn't do in the continuous integration test infrastructure. Do you have a software bill of materials for your network stack? Check for quality in all components. If you remember the left-pad disaster, this phenomenon of people importing low-quality code from sources with no reliability whatsoever has long reached the microcontroller world; in the shape of Arduino "libraries", mbed repos, and since the dawn of C in the shape of people that really should realize they're developing a software product telling themselves they don't need to understand the code they're just copying.

Answer 3

Lots of good advice has been given.

While using the fuse bits to write protect, it means if a security vulnerability is found the device needs to be replaced to deploy a fix so you gotta be sure you are ok with that when making it write only.

Some other things to look into is the tls and dtls offered by the wolfssl stack. According to them the memory footprint is smaller and better performance. There is also an alternate you could look at named mbedtls which is even smaller footprint according to the openwrt project.