The horse that hides the hack Friday, 10 February 2017

News article written by Corbett Communications. The statements made or opinions expressed do not necessarily reflect the views of Engineers Australia.

How do you know if a Trojan lurks in your field programmable gate array (FPGA) design? You might scratch your head wondering what such a low-level intrusion could possibly accomplish. One example is a tweak to logic that decides if a given instruction requires super-user status to execute, according to the US-based Electronic Engineering Journal. This type of attack allows a specific protected instruction to slip through without super-user status and create a bypass of built-in security.

The way this type of attack is built leverages the look-up table (LUT), the heart of the FPGA (logic is implemented by 4- or 5-input LUTs that can implement any function of those inputs. The LUT’s contents are set when the device powers up and loads its program from non-volatile memory). What happens with the LUT, is all inputs are tied together so that of all the functions theoretically possible from the LUT, the only ones that will ever be executed are the inputs 0000 or 1111. Functionality with a one-input LUT is limited to four functions: constant 0, constant 1, the input state, or the inverse of the input state.

FPGA tools normally start from high-level hardware languages and synthesise and optimise to get the LUT configurations. But a team from Technische Universität Wien in Austria was able to get in and interfere with the LUT and created explicit LUT logic but it doesn’t alter normal behaviour of the circuit at this point. There’s also the challenge of replacing an unaltered EDA tool installation with the hacked version that TU Wien postulate is possible through an internet-based attack.

An additional trick is the circuit is never placed into an actual design file where it could be inspected, instead it’s added to the in-memory representation while the file is read by the hacked synthesis tool. While the stealth Trojan circuit does nothing until activated, another tool is hacked. The LUT, with its 16 memory addresses from four inputs only has two (MSB and LSB) being used, the remainder 14 memory cells can have anything put into them. The TU Wien team defined two 7-bit flags encoded in the cells, one to ‘keep’, the other to ‘flip’.  Those 14 bits are divided in two, with seven each focused on the LSB and the MSB upon activation.

When the hacker creates a bitstream, a compromised backend tool can be leveraged. This particular too has functionality that searched for rogue cells. Once found, it can change the behaviour of the MSB or LSB according to the specified instruction, keeping as is or flipping the bit. The circuitry at this point is active and any flipping done is on the bitstream output. The in-memory representation is unaltered so not to arouse suspicion; the triggered Trojan would never be visible by the tools.

In summary, the in-file versions have no extra LUT logic; the in-memory version has inactivated extra LUT logic, and the bitstream has activated LUT logic. Bryan Moyer, writing for the EE Journal, said if it was done crudely, security tools which identify unused or lightly used circuits, unused or redundant inputs might detect such an attack. He said it was possible to work the malicious LUTs into the normal functionality so the mal-Logic would be used under normal circumstances before being activated, thus escaping detection.

However, studying a synthesis tool and what it generates might make it possible to identify a pattern that can be leveraged in the tool.

Moyer said the only solution that could catch the Trojan would be a formal equivalence checker between the final design and the bitstream. But the problem is bitstreams use an unpublished format so no one other than the FPGA maker would be able to make such a tool. The answer to this, Moyer suggested, is that FPGA makers publish their bitstream formats so that such equivalence-checking tools can be built.

Read the Krieg et al paper: Malicious LUT: A Stealthy FPGA Trojan Injected and Triggered by the Design Flow.

Author: Desi Corbett