EMBEDDED SOFTWARE SECURITY ANALYSIS IN REWIRE

The REWIRE project envisions a scalable cybersecurity solution for open-source and open-specification hardware and software for IoT devices. University and industry partners of the REWIRE project will collaborate on researching and developing a tool chain that ensures that cybersecurity is integrated throughout the life cycle of a device on a zero-trust basis. This will include security assurance of processes starting at device on-boarding to a system, bootstrapping, securing communications with other devices on the REWIRE network, and software/firmware verification, including secure updates.

Secura is researching and developing a link of this tool chain that will ensure security threats can be effectively discovered and treated through an automated firmware validation and verification mechanism, targeted to device firmware used in smart cities, smart satellites, and smart automotive.

BINARY ANALYSIS TECHNIQUES

Using state of the art binary analysis techniques, Secura is developing a module that can detect flaws in software. Since the devices used in these contexts generally have very specialized code, detecting such flaws can be difficult. Software relies on certain hardware components that can vary from device to device, and in many cases the source code is not available. Secura's testing module therefore emulates the code as if it was running on its original hardware, and in the REWIRE project as a whole design decisions are made for the hardware architecture of the devices. This allows accurate analysis of flaws, contributing to more secure embedded software.

Embedded software security analysis in REWIRE

The firmware unpacking is done through a combination of frameworks for processing binary files (like firmware). These tools produce a file system containing the configuration files, libraries and software run on the device, and if a full firmware image is available, can include a boot loader and kernel.

Since the firmware will be emulated, it is important that its integrity is preserved, and references, such as symbolic links, libraries and configuration files, are also intact. Therefore, a sanitization step is generally run to check whether such references are in place before actually emulating the firmware.

RUNTIME ANALYSIS

The runtime analysis refers to the moment the software in the firmware is ready to be run. This can mean it runs on hardware, but since the firmware in scope runs on various devices, with possibly some peripherals, the runtime analysis cannot rely on the hardware being available. Assuming so would mean the verification would scale poorly, as many devices would have to be used. Therefore, a runtime analysis generally relies on many techniques that allow the bytecode to be evaluated without running it on the hardware it was compiled for. The techniques used in static code analysis are taint analysis that detects any injection vulnerability patterns in the source code, and symbolic execution as a means of analyzing a program to determine what inputs cause each part of a program to execute, and therefore, might cause issues.

Dynamic analysis typically consists of symbolic execution, taint analysis, and fuzzing - an automated software testing method that injects invalid, malformed, or unexpected inputs into a system to reveal software defects and vulnerabilities.

COVERAGE GUIDED FUZZING

When emulating the firmware in this manner, it can be fuzzed with great control, as it can check every detail of the virtual CPU used to emulate the firmware. It should come as no surprise that the fastest way to detect vulnerabilities in firmware is coverage guided fuzzing, a technique where the branches of the software reached by providing a certain input are tracked, and input which reaches new branches is used for further testing. In this manner, a large part of the software can be tested quickly.

"The output of the firmware verification will serve as input for a theorem prover on a blockchain, which attests the correct functioning of the device." The results of the verification process will be used as input to craft a theorem on the security of the device. Furthermore, any vulnerabilities discovered in the verification process will be used as input for the threat analysis tool, which will also be implemented within the REWIRE project.