Foundations of Trust Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

8 hours 10 minutes
Video Transcription
Hi, I'm Matthew Clark. And this is Module four, Root of trust.
Congratulations. We've completed module three. This slide shows our progress towards our certificate of completion.
Let's begin our new module with less than 4.1 foundations of trust. Part one in this lesson will look at Microsoft seven properties of a highly secure device
and we'll discuss root of trust. So let's get started.
If you had to design ah, 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 coyote devices?
Well, one answer might be, I don't know, Clark. That's why I'm taking this glass. 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 the device?
If you guessed hardware root of trust will greet, 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. AH, 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, unfortunately identity that is inseparable from the hardware.
Unfortunately, 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 Coyote, were 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 gonna 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 to find 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 short sighted.
Items stored in the trusted computing base are meant to be mostly static, so it would be difficult to update them.
And this includes Onley, the items necessary to ensure that the system functions in a secure manner.
When we discuss TPM s and dice, you'll see the importance of this.
You want to design a secure I ot 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 medicated
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 involved the hardware, software and network and so forth. While physical controls
include controls to address tamper resistance,
Um, such as using a poxy resin on silicon ships or disabling debug ports and controls to address tamper detection, including the use of hardware that enables the secure boot or measured boot.
An 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 I ot device so that a failure and 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 on Lee effects that one area and failures cannot be used to cross from one security zone into another.
So to achieve this, you want hardware enforced barriers between software components.
The fifth property is certificate based authentication, and we're gonna 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 i. O. T devices.
A signed certificate proven by an unfortunate will Cryptographic key provides the best device, identity and authenticity.
And don't get me wrong. There's still challenges with managing an x 0.509 certificate. But a well considered architecture er can address those concerns.
Now. Using symmetric keys is simply not a secure is using certificates, and most hardened chips are gonna ask for a P K I, anyways, or at least support it.
And using a shared password is simply no longer a viable solution with the changing i o. T. Legal landscape.
The six property is renewable security, And what do we mean by renewable security? Well, I admit this is always seemed like a marketing term to me. You read about this and 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,
um, 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.
These were 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 could design better software or patch the software that they have,
as in Oh, am you need to decide during the device design process? Will you give the end user the ability to report re 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 P I or data that could identify a person?
Well, we're gonna look at some really cool case studies about personal data and module seven.
It's critical to state that items two through seven on Microsoft List all rely on the successful implementation of the first property. Ah, 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 I o. T devices need to have a strong root of trust.
When we use the term trust as it relates to Coyote were 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, were implying that the roots of trust can come in different forms in different strengths, with some being stronger than others.
Many times a ruder trust is defined in relation to us very specific technology, such as a TPM or HSM,
both of which provide a strong root of trust.
Sometimes we use dykes,
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.
Groups of trust, our best enabled through hardware, meaning that at a minimum, ah, silicon ship and protected storage and usually includes 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 seven properties of a highly secure device,
and we define roof trust using a big old tree to help visualize it.
I'll see you next time.
Up Next