How can you secure embedded software from vulnerabilities?

As mobile devices become very important part of daily life, it is imperative to secure both SW and HW. They are used for not just communication but also to access financial and personal information. This can can lead to serious financial and personal stress. Embedded SW security must be maintained starting from the development to all the way running on HW.

Another risk associated with insecure embedded software is the potential for misleading product advertisements. These ads might showcase a device's positive features while conveniently omitting any mention of security vulnerabilities. This omission can mislead consumers, making them unaware of the risks associated with hacking or breaches due to the device's compromised software. As a result, consumers might make purchases without understanding the full scope of potential dangers to their privacy and security.

I was developing a firmware for a startup couple of years ago to run on an embedded device which essentially acted as the lock for a smart bike. The lock was gathering and sending the location data as well as communicating with the users. I tried to design a state machine and implement plenty of functions to follow the 'single responsibility' rule. In one of these functions I used 'sprintf' to fill a string with a number, but I had miscalculated the length of the resulting string and as a result, an stack overflow was happening. In test phases, we lost some bikes due to this bug, since the stack overflow caused the device fail and irresponsible. Hopefully after several real-world debugging sessions I could find the bug and fix it.

With out hardware anchored root of trust it is very hard to guarantee security of Embedded software running on a system. Security starts from time of development by following secure SW development, static/dynamic code analysis. Make sure SW is sign verified every time it boots on CPU. Also make sure run time authentication done when ever sensitive data being accessed. It's also suggested to do SW measurements on every boot to make sure any of secure configurations changed. Especially during OTA it is imperative to guarantee end to end connects are secured and user authenticated.

The dominant programming language in most embedded systems is C. C is a concise, near-to-hardware, powerful language. However, it has some serious pitfalls as well. In fact, the memory management is thoroughly up to the programmer. You can do whatever you want, and C won't complain, but at runtime unknown, nondeterministic behaviors may arise. Other than that, some dangerous but legal actions in C, like stack violation, null pointer de-reference or ... may lead to a HARDFAULT and the device can die easily. To avoid all there, using a static or dynamic checker, like Valgrind or various linters may help.

Mobile users are agnostic to what's being run on the HW. But providing secure embedded software guarantees data privacy and security. As these devices are becoming defacto personal wallets for financial transactions it would greatly reduces risks of monetary losses. Embedded SW also controls how underlying HW cunctions, but by it self can not solve security issues. Both SW and HW need to work together for tighter control of code execution and data protection.

Developing Embedded SW is art. It takes intimate understanding of both HW and SW. In stack based CPU architectures there are many ways you inject vulnerability. Code execution can be changed by affecting the flow of execution. This is not necessarily SW interfaces, this can be done at HW level side channel attacks. It is important to add robust checks and validations especially when external data or pay loads are accepted.

If you are an intermediate C programmer, I urge you to read the "Learning C: The Hard Way" by Zed A. Shaw and watch its companion videos. It covers most of possible programming issues and misconceptions of memory management in C programming using a step-by-step, practical approach.