Hardware trojans and the threat of covert channels in software.

In this article I will be discussing hardware trojans, covert channels, and malware. Just like software can be dangerous it is important to know that hardware is even more dangerous. It is not feasible to know what your hardware is actually doing because certain hardware trojans are undetectable. In addition, covert channels can allow software to communicate in ways the user is unaware of. Covert channels are very hard to detect, and are very easy to implement.

Introduction

Security has different domains. Typically when people think of information security they are primarily focused on the software domain, but it is also important to remember that the hardware domain is just as important. There have been recent academic discoveries which have enhanced the capabilities of attackers (advanced persistent threats) to create newly evolved stealth hardware trojans which cannot be detected. In addition to this we have the possibility of covert channels which can hide the communication behavior of malware in the software domain, allowing for stealth malware as well.

Hardware trojans are going stealth

While there are theoretical methods in development for detecting certain kinds of hardware trojans such as the “clock sweeping technique” (Zheng, Wang, & Bhunia, nd) and “exhaustive testing of k-bit subspaces” (Lesperance, Kulkami, Cheng, 2015) , there also theoretical techniques for producing undetectable hardware trojans. These undetectable hardware trojans represent a serious threat and because of the nature of this threat we may have to assume that hardware not produced in a trusted way, through a trusted foundry, with a transparent supply chain, could be compromised. In 2013 two academic papers were released, one by Becker, Regazonni, Paar & Burleson titled: “Stealthy dopant-level hardware trojans” which made news in the information security blogsphere, and by Wei & Potkonjak titled: “The undetectable and unproveable trojan horse”. These two papers offer a theoretical basis for producing stealth hardware trojans from which with we have no way to distinguish in order to detect.

Ethereum and securing the supply chain with Provenance

Ethereum is described as a “world computer” by it's evangelists, but to be more technical Ethereum is was intended to be a blockchain with a Turing complete programming language, allowing for generalized programmability in the development of DAOs. DAO stands for decentralized autonomous organization, and another acronym would be DAC which stands for decentralized autonomous corporation. The programs on Ethereum are called “smart contracts”, and are self enforcing because the code is supposed to represent the rule(s). Ethereum is categorized as a Bitcoin inspired project in that it took some of the concepts which Bitcoin uses, such as proof of work, and uses solutions like the blockchain, but it does goes further, taking risks Bitcoin did not take (Turing complete programmable) in order to solve the problem of creating DAOs/DACs. Ethereum aims to be very flexible, allowing for open experimentation.

Securing the supply chain is not going to be an easy task. The current trends in technology point to decentralized solutions such as the solution provided by Provenance which is expected to run on Ethereum but even in this case the fact that Ethereum is Turing complete (undecidable) means there could be decentralized apps which behave in unexpected ways, and because Ethereum itself is software it does not solve the problem of hardware trojans which may in fact be able to compromise the machines running the software. The problem of hardware trojans remain an open problem and stealth hardware trojans seem to be a problem which can only be solved by securing the supply chain itself.

Malware is going stealth

While covert channels have always existed in some shape or form, the techniques involved and difficulty in detecting covert channels currently favors the malware makers. Covert channels are communications channels which transmit information in unexpected and often undetected ways. A machine may have a firewall, it may have have intrusion prevention/intrusion detection systems, it may have the latest anti-virus/anti-rootkit software, but it doesn't matter. The covert channel could use anything from the IP packet identifier field, to timing, to inaudible sounds.

Defense mechanisms for covert channels include isolation as is used in the QUBES operating system, and detection. Process isolation for example may attempt to put every process in it's own sandbox so that processes cannot communicate in unexpected ways. Detection relies on statistical analysis and is a lot more difficult than isolation.

A covert channel requires a shared resource, and while isolation can minimize the threat, it's the noise level which can make statistical analysis very difficult. In a covert IP timing channel if there is significant traffic then it becomes infeasible to detect the covert transmission through the noise. Covert channels are currently useful to botnet and malware makers.

Conclusion

We cannot trust our hardware or our software. The reason we cannot trust software is we don't know what it is doing. It is not simply the fact that there could be an underhanded bug, logic bomb, or other issue with the software, but also the very real risk that there could be a covert channel which leaks information. In addition our hardware cannot be trusted because we do not have an ability to trust the foundry that makes the chips. We assume we can trust companies such as Intel, or AMD, but in reality we have no way to determine whether there is a backdoor in a particular model of a particular chip or not because the backdoor itself would be undetectable.

These risks can be mitigated but it is not easy. For this reason it may make sense not to put too much trust in any hardware or software. It may be that there is a backdoor hidden in a particular hardware or software but it may also be unlikely that all hardware and software have backdoors. Figuring out which hardware components and which software to trust is part of the challenge of mitigating these risks.

References

Becker, G. T., Regazzoni, F., Paar, C., & Burleson, W. P. (2013). Stealthy dopant-level hardware trojans. In Cryptographic Hardware and Embedded Systems-CHES 2013 (pp. 197-214). Springer Berlin Heidelberg.

Becker, G. T., Regazzoni, F., Paar, C., & Burleson, W. P. (2014). Stealthy dopant-level hardware Trojans: extended version. Journal of Cryptographic Engineering, 4(1), 19-31.

Brewster, C. Semantic blockchains in the supply chain.

Lesperance, N., Kulkarni, S., & Cheng, K. T. (2015, January). Hardware Trojan detection using exhaustive testing of k-bit subspaces. In Design Automation Conference (ASP-DAC), 2015 20th Asia and South Pacific (pp. 755-760). IEEE.

Rutkowska, J., & Wojtczuk, R. (2010). Qubes OS architecture. Invisible Things Lab Tech Rep, 54.

Shield, J., Hopkins, B., Beaumont, M., & North, C. (2015, January). Hardware Trojans–A Systemic Threat. In Proceedings of the 13th Australasian Information Security Conference (AISC 2015) (Vol. 27, p. 30).

Sharifi, E., Mohammadiasl, K., Havasi, M., & Yazdani, A. (2015). Performance analysis of Hardware Trojan detection methods. International Journal of Open Information Technologies, 3(5), 39-44.