Foundations of trust: Part 1

Hi, I'm Matthew Clark. And this is Module 4: Root of Trust. Congratulations. We've completed Module 3. This slide shows our progress towards our certificate of completion. Let's begin our new module with Lesson 4.1: Foundations of Trust, Part 1. In this lesson, we'll look at Microsoft's seven properties of a highly secure device, and we'll discuss root of trust. So let's get started. If you had to design a highly secure device, what would be some of the distinctive attributes or qualities that you would expect to find in that device? In other words, how do you secure IoT devices? Well, one answer might be I don't know, Clark. That's why I'm taking this class. So why don't you tell me? And sure, that's an easy answer, but let's try a little harder. What are some of the things that you would like to see in a device? If you guessed hardware root of trust. Well, great. You've been paying attention, but what else? Well, Microsoft wrote a paper on this, and there's a lot of really smart people over there. So let's take a look at what they had to say and see if we could pick up a few answers. The really smart people at Microsoft came up with this list of seven properties of highly secure devices, a hardware-based root of trust, a small trusted computing base, defense in depth, compartmentalization, certificate-based authentication, renewable security, and failure reporting. The first property is ding, ding, you guessed it, hardware root of trust. And that's what this module is all about. We're going to define the definition of a strong hardware root of trust throughout this module. But basically, what this property is about is establishing a unique unforgettable identity that is inseparable from the hardware. An unforgettable identity is an identity that cannot be falsified, and being inseparable from hardware means that the hardware has properties such that it protects the identity and cannot be removed from it. And it contains basic components and properties or building blocks that promote trust. When we use the term "Trust" as it relates to IoT, we're stating that we have confidence in the identity and secure operation of a device. One outcome of a properly designed root of trust is that the device becomes resistant to tampering, such as side-channel attacks, and we're going to talk about attacks to roots of trust throughout this course. The second property Microsoft identified was a small trusted computing base. A trusted computing base is defined as the collection of hardware, software, including encryption and firmware that is critical to the secure operation of the device. Well, that sounds good. So would you want to store all of your software in the trusted computing base in order to protect it? While that might sound tempting, it would be just a little shortsighted. Items stored in the trusted computing base are meant to be mostly static, so it would be difficult to update them. And this includes only the items necessary to ensure that the system functions in a secure manner. When we discuss TPMs and DICE, you'll see the importance of this. You want to design a secure IoT device so that the majority of software is outside of this trusted computing base. You want to separate trusted from untrusted and self-protecting layers. You also want to design the device so that private keys are stored in a hardware-protected vault which is inaccessible to software. The third property is defense in depth. And this is a common cybersecurity principle that transcends literally every security discussion. It involves layering defensive controls in a manner that there are multiple ways that a threat could be mitigated, so that if one attack vector is successful, then the device will still be protected. Typically, we talk about layering technical controls because as technologists, that's kind of how we think. But proper defense in depth requires careful consideration and a strategy that involves considering controls from multiple disciplines, including technical, physical, and administrative controls. And technical controls involves the hardware, software, and network, and so forth. While physical controls include controls to address tamper resistance, such as using epoxy resin on silicon chips or disabling debug ports, and controls to address tamper detection, including the use of hardware that enables the secure boot or measured boot. And administrative controls includes the framework selection, policy development, separation of duties, compliance, and auditing. The fourth property is compartmentalization, which builds on and goes along with a small trusted computing base and defense in depth. So do you want to design a secure IoT device so that a failure on one component of the device requires a complete reboot of the entire device? Well, probably not. You'd want to design it so that a failure only affects that one area and failures cannot be used to cross from one security zone into another. So to achieve this, you'll want hardware-enforced barriers between software components. The fifth property is certificate-based authentication, and we're going to keep driving this point home. But right now, certificate-based authentication is one of the strongest types of authentication and should be seriously considered for IoT devices. A signed certificate proven by an unforgettable cryptographic key provides the best device identity and authenticity. And don't get me wrong, there's still challenges with managing an X.509 certificate, but a well-considered architecture can address those concerns. Now, using symmetric keys is simply not as secure as using certificates, and most hardened chips are going to ask for a PKI anyways, or at least support it. And using a shared password is simply no longer a viable solution with the changing IoT legal landscape. The sixth property is renewable security. And what do we mean by renewable security? Well, I admit this, as always, seemed like a marketing term to me. You read about this in Microsoft documents, but it never really feels like there's a lot of meat on the bones, but let's go with it. It's a concept that security stays fresh and needs to be updated to address new vulnerabilities via delivery and application of security updates and that the device protects against failures. Microsoft points out that without renewable security, a security incident will require disconnecting devices from the Internet and then either recalling those devices or dispatching people to manually patch every device that was attacked. The seventh property is failure reporting, and there's not a lot to say on this one. It seems to be pretty self-explanatory, but these are good for the company so that the company can learn from actual devices in the field. What were the conditions that led up to a device failure? So hopefully, they can design better software or patch the software that they have. As an OEM, you need to decide during the device design process, will you give the end user the ability to report failures to its manufacturer? And if you do, then what are you going to do with that data? What will be collected? Will it contain PII or data that could identify a person? Well, we're going to look at some really cool case studies about personal data in Module 7. It's critical to state that Items 2 through 7 on Microsoft's list all rely on the successful implementation of the first property, a hardware root of trust. None of these other properties can exist or work properly without the first one serving as a foundation. So let's take a few minutes and really try to define what root of trust means. Let's start with an analogy. I love this picture of this tree. You can see the massive roots that provide stability and strength for the rest of the tree. The trunk, the branches, and the leaves of this tree all have trust in these massive roots to keep the entire tree upright when storms come along. I think this picture provides a good reference for what we're trying to illustrate when we say that IoT devices need to have a strong root of trust. When we use the term "Trust" as it relates to IoT, we are stating that we have confidence in the identity and secure operation of the device. When I use the word "Trust," I want you to think of it as a verb, meaning that it requires action. It's not something that you can achieve without doing very specific actions. And when we apply the adjective strong to a root of trust, as in saying a strong root of trust, we're implying that the roots of trust can come in different forms and different strengths, with some being stronger than others. Many times a root of trust is defined in relation to a very specific technology such as a TPM or HSM, both of which provide a strong root of trust. Sometimes we use DICE, which is considered a lightweight root of trust, and we're going to go into each one of these technologies deeper and point out which components are required. The roots of trust are best enabled through hardware, meaning that at a minimum, a silicon chip and protected storage, and usually include some other items that we're going to discuss in the next lesson. Well, that's it for this lesson. So how would we summarize what we learned? Well, we discussed Microsoft's seven properties of a highly secure device, and we defined root of trust using a big old tree to help visualize it. I'll see you next time.