“What verification is performed by the operating system on boot? Is there a mechanism by which the operating system verifies that the binary image is intended for a NetBurner product, and/or was generated from NetBurner tools? Can you provide a description of any sort of signing or validation that takes place upon reception of a flash image and, or at boot up?” If these kinds of questions come up for you when researching new platforms and development kits, you’re not alone.
For engineers with security on their minds, it’s often not enough to know what security ciphers and protocols your devices support for outgoing or incoming connections. In many cases the security on the device itself also comes into question. These security considerations generally revolve around ensuring that the application being programmed into a device, or loaded by the device on boot, is the application that is supposed to be there, and preventing malicious third parties from making unauthorized changes to the device.
NetBurner strives to make security a priority for our devices and the applications that are running on them. In order to answer many of the questions that we get from customers regarding module and boot security, we’ve outlined how one of our more popular NetBurner devices, the MODM7AE70, boots, and outlined the many options developers have for making the boot process more secure.
The Boot Process
The first part of the boot process is controlled by a small microcontroller completely separate from the main processor. This part of the boot process cannot be compromised by any means short of hooking up a hardware debugger to the MODM7AE70. The microcontroller code cannot be extracted since the fuse bits are turned off. The only operation that could be performed is a full erase and reprogram with physical access to the hardware debug interface of the MODM7AE70 processor.
Once the main processor boots, it attempts to load the main application from application flash memory located on the processor itself. The application is stored as a compressed image with a checksum.
With the general boot process described, we’ll now dive into the various options available for making a device more secure. The question really boils down to how paranoid do you want to be? NetBurner modules provide options for even the most security minded developers. That said, there is always a balance between security and ease of use. Choosing some of the options listed below will make using the tools for development substantially more painful.
Username and Password
At the most basic level, you can set a configuration system username/password. This will prevent application updates to the device without a valid username and password being provided. To enable this, go into the device’s configuration system and enable it. This can be done through the web interface, or serially. Note that just having values saved for the username and password will enable this security measure.
The consequence of this setting is that you will now need to do code updates with the WGET utility with username/password, or by logging into the configuration web page and using the “Update Application” option.
Update with TLS Only
This option will force any changes to the configuration system and application uploads to use TLS only. This means that the device will be required to have a valid certificate and the secure config server will need to be enabled. Fortunately, both of these are fairly easy to accomplish. Automatic certificate generation is on by default in our modules using our NNDK 3.x tools. This will happen during the SSL/TLS initialization process. Enabling the secure configuration server is also fairly straightforward. This is done by adding the following function call to your
// False enables both TLS and non secure updates EnableSecureConfigServer(true);
This option will require application updates to be code-signed. Any attempted update with an application that isn’t properly signed will be rejected by the system. code update to flash unless it is signed. This can work with the eclipse development tools and without options 1 or 2 above, which makes development much simpler. The downside is it requires that anyone compiling application code for the device has access to the signing private key used for the signature.
We have an example demonstrating this that can be found in the developer tools at:
Application Hash Codes
To verify that the application currently running on a device is what you’d expect it to be, it’s possible to generate and then publish/show a secure hash of the current running application code. This can be used to ensure that the application wasn’t swapped out from under you. To see how this is setup, please see the example located in the developer tools at:
Things to Consider
When trying to establish how much security is appropriate for your own products and applications, it’s important to take a minute and ask some questions about what your device is doing, where it’s located, and what the proper tradeoff is with regard to impact on development. Some key points to consider are listed below.
- How painful is it to cause a bricking of the device due to a loss of username/password/private key?
- How will security measures add additional steps and complexity during development?
- What is your threat model?
- What are you protecting? Protecting the message on a street sign, or the temperature of a freezer is different than protecting nuclear launch codes.
- What is your security perimeter / exposure surface?
- Is the hardware physically secure?
These questions will have an impact on the measures you’ll need to take to ensure the most appropriate level of security for your designs. NetBurner is committed to ensuring that even the most stringent security standards can be met with our modules and development tools. If you have any questions about best practices or around specific requirements, please don’t hesitate to reach out to us as firstname.lastname@example.org.