Zero Trust Security: What if the ESP32 really had a backdoor
There was a scare on the net for a few days: Allegedly, the ESP32 processor has a backdoor. Fortunately, it quickly turned out that the danger was low and the term "backdoor" was not appropriate (to put it politely). As there are probably hundreds of millions of ESP32s installed and in use worldwide, this would have been a disaster.
As systems engineers, we cannot prevent such dangers, but we can protect ourselves against them. An important development pattern for this is zero trust security:
ESP32 "Back Door"
The ESP32 is a Economical and energy-saving microprocessor familywhich is ideal for embedded systems. On March 6, 2025 Tarlogic claimedto have found a backdoor. This news spread quickly due to the widespread use of ESP32.
But it soon emerged that the original reports were exaggerated. How Hackaday explainsIt was not a deliberate backdoor, but rather a vulnerability in the Bluetooth implementation that could be exploited under certain circumstances. A patch to fix the problem has already been announced.
Hardware exploits are nothing new
There have been incidents of backdoors in hardware for decades. For example, back in 2005, the German Federal Intelligence Service (BND) discovered a Backdoor in the surveillance systems of NetBotz. The Federal Office for the Protection of the Constitution was only informed of this in 2015.
It doesn't always have to be malicious intent: Computrace is an anti-theft device integrated into the BIOS/UEFI. Computrace has been criticized for the fact that it can act like a backdoor, i.e. it can be activated without the user's knowledge and is difficult to remove. If it is installed on a used laptop, for example, even reinstalling the operating system does not protect against damage.
Architecture as the foundation for security in software and systems engineering
Although software is more susceptible to security problems, it is also much more advanced. One of the reasons for this is that certain architectures have become established in software development that take attack security into account from the outset. If security is not anchored in the architecture from the outset, insecure systems quickly emerge.
We see this in practice when we observe how frequently apps are updated on mobile devices:
- The architectures of smartphone apps are so mature that an update only rarely leads to problems
- Most updates to smartphone apps are triggered by updates to the built-in libraries. These in turn are often updated to close security gaps. In this way, the apps remain secure.
Software applications follow architectures that enable fast and robust updating, allowing security gaps to be closed quickly. Among other things, this is made possible by Semantic versioning.
Zero Trust Security - security through mistrust
Zero Trust Security means that a system never trusts blindly - neither internal nor external components. In a modern architecture, this means that every access is strictly checked, regardless of whether it comes from a network that is considered "secure" or not. This way of thinking is essential, especially for systems that combine software, electronics and mechanics. For example, an IoT device, a machine controller or a networked vehicle could consist of different modules that are only allowed to communicate with each other if they can authenticate and authorize each other.
Even if the idea behind it makes sense, this is not always perceived positively by customers. Apple customers in particular have been unsettled by such messages after replacing batteries. Such messages can only be switched off with the help of Apple support, as they have the necessary crypto keys.
Implement Zero Trust Security
The implementation of Zero Trust requires several measures: On the hardware side, this can be achieved through secure boot mechanisms and Trusted Platform Modules (TPMs) that only execute signed code. Electronic control systems must use cryptographically secured communication channels to prevent tampering. In software development, containerization and sandboxing help to contain attacks. Role-based access systems (RBAC/ABAC), we can ensure that each component only receives the rights it really needs.
Established procedures for implementing Zero Trust include, among other things
- Least Privilege PrincipleEnsures that each component only has minimal rights;
- Continuous AuthenticationIdentities are checked regularly;
- Software Defined Perimeter (SDP)A system only sees exactly those parts of the infrastructure that are necessary for a particular request.
Zero Trust Security in the system architecture
To ensure security, including Zero Trust Security, we need to consider it from the outset, i.e. in requirements and system architecture. Security introduced after the fact all too often leads to gaps in coverage. For example, an important aspect of system composition is the identification of interfaces. Even at this stage:
- Each interface must be examined from the point of view of attack security
- Interfaces that are of little importance for the system but could be relevant for attack security are identified.
One example: In the 2010s, there was an increase in ATM break-ins. In 2015, for example, a perpetrator in Germany was filmed robbing an ATM. opened the ATM, plugged in a USB stick and got the machine to dispense cash. Presumably the USB port service interface has not been checked for attack security and is therefore not sufficiently physically (or otherwise) secured.
Conclusion
Such concepts are already established in large IT systems, but need to be adapted even more for embedded and industrial systems. But one thing is clear: the future belongs to architectures that are designed to be secure from the ground up - and zero trust is an indispensable principle in this respect.
Image sources: Photo by Irham Setyaki on Unsplash, Wikimedia
