Hardware-Based Security: Trouble and Hope

Abstract : Perhaps as a result of the increasing complexity of computing systems, we see too many security mechanisms (for embedded systems or any other system) focus on only one level. An example of his limitation is that the use of typesafe languages may eliminate certain classes of vulnerabilities but may come at a performance and usability cost and have been successfully compromised via light-bulb-induced memory errors. (Looking only at the language level also neglects how much of the underlying libraries, OS, and firmware may be written in very primitive languages, such as assembler.) One might even go out on a limb and say that we need a new kind of composition theorem: not between "peer" modules, but rather across layers and organizational boundaries. Security architectures to control code updates and to authenticate devices are based on cryptographic protocols. Best practices tell how to soundly engineer protocols from the primitives and key lengths that cryptographers deem secure. However, the security of these primitives are themselves based on assumptions. History has shown these assumptions don't always remain true as long as anticipated. Sending a self-protecting embedded system out into the cold, cruel world also often requires that the system itself be able to keep and use cryptographic secrets. Here again, history shows that keeping secrets is difficult. Among the reasons for is the fact Industry is open to designing and deploying hardware-based techniques to enhance security. Perhaps as a consequence of trying to adhere to Moore's Law, hardware vendors are now giving us more cores than we know what to do with and are desperately searching for applications, usage models, and a business case. This position gives us an opportunity to rethink what a CPU does and to see these changes happen in the real world.