Security, just like quality and many other embedded system attributes, must be considered at the start of the development cycle. Developers can’t build their system and then add security at the end. With more and more systems starting to connect to the Internet, there are more than a dozen best practices developers should follow to start securing their systems. Let’s explore several that any team can implement.
Start using ARM Trustzone
ARM Trustzone has been available on application processors for quite some time and it has been announced that ARM Trustzone will be available on new microcontrollers soon. While we may not be able to use Trustzone right now in a microcontroller environment, developers should be starting to explore its implications and how it can be used to write more secure software. If you have an ARM application processor, now is the time to start putting Trustzone to work.
Follow Language and Industry Best Practices
There are several programming language and industry best practices standards that embedded software developers should be using. Using MISRA-C/C++ can ensure that best practices are followed that use a subset of the chosen language. MISRA should be used regardless, but from a security standpoint and if developers are using C, then becoming familiar with and following the best practices in Cert-C is highly recommended. Cert-C is designed to provide recommended coding practices that prevent security vulnerabilities in software.
Digitally Sign and Encrypt Firmware Updates
Any device that is connected to the Internet is going to need feature updates and bug fixes pushed to it. In order to prevent unauthorized firmware updates, developers should consider digitally signing and encrypting their firmware images. Many systems I encounter simply accepts any new software it encounters. Developers should make sure images are authenticated before ever touching them.
Validate the Application at Start-up
Would-be hackers may try to inject new software onto the system during start-up. It’s always a good idea to use the bootloader to validate that the current image stored in ROM and the code running in RAM is what should be there. There are many ways to do this but a very simple check would be to place a CRC that is validated on start-up. It’s better than nothing!
Monitor Stack and Buffer for Overflow
Overflowing the stack or a buffer can be a great way to start injecting malicious code into a system. Developers should monitor their buffers and stack space to ensure they are not able to overflow. This can be done manually by monitoring the position pointer or creating guard zones that warn of an impending overflow. Most RTOSes also include a stack overflow monitor. Make sure that it is not only turned on but that there is code to handle the system when this state occurs.
Lock Flash Space
It certainly is tamper-proof but one extra hurdle to throw in front of a hacker is to lock the Flash program space. Locking the Flash at end-of-line will help prevent someone who has physical access to the device from being able to read out