Trusted Platform Module 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. This is Lesson 4.7.
Trusted platform module. Part one
in this lesson will introduce the trusted platform module will compare the T, e and TPM and talk about the architecture, er, roots of trust and measured boot.
The trusted computing group created the trusted platform module, or TPM, and released it for use in 2003.
The TCG defines the TPM functionality of both protected capabilities and shielded locations. It does not define the implementation of a TPM
vendors air free to implement TPM in different ways as long as they meet the protective capabilities and shielded location requirements
TPM Zehr widely used today and nearly every computer for disk encryption.
They're used in other applications, such as VPNs or other 8021 X compatible solutions.
And there's two types of TPM that we're really gonna talk about. Discreet or external chips, which are dedicated hardware are integrated chips which are part of a system all chip
the TPM that we will focus on will be physical devices. It's worth pointing out here that the TPM has to be physically added to the PCB, the printed circuit board and this is an important concept these chips air soldered on during manufacturing.
You can't go back and add them afterwards, and you can't take them off and apply them to a different system.
You either have the TPM or you don't
let's discuss the differences between a trusted platform and a trusted component.
A TPM is not a trusted platform.
Trusted Computing Group defines a trusted platform as a computing platform that has a trusted component, which is used to create a foundation of trust for software processes. In other words, a trusted platform has it its foundation, some trusted component, which is called a root of trust.
And the TPM forms that root of trust. So to recap, a trusted platform is an entire system, and the TPM is a permanent component of that trusted platform because it's attached a hardware.
So let's talk about how a trusted execution environment and a TPM compared well compared to the T E. The TPM specifications are more restrictive.
A trusted execution environment is a separate execution environment that provides security services and isolates access to hardware and software security. Resource is from the rich operating system and applications.
The TPM works with the t E. They're not competing standards or alternate solutions. The TPM is a secure, crypto processed brought measurement and assurance of a platform secure state,
while the T E provides an environment in which to execute those TPM processes. So the trusted execution environment and the trusted platform module do different things, but they work together.
The TPM specifications defines too generic portions of the TPM, both of which are implemented in hardware. They're protected capabilities and shielded locations. The protective capabilities are function whose correct operation is required in order to create trust
in the shielded locations are in area where data is protected against interference
and outside exposure. So how are they related
on Leah Protected capability Can access, read or write a shielded location.
So remember vendors air free to implement a TPM in different ways. As long as they adhere to these basics,
the areas in pink or what we're talking about. We're going to go into detail about the keys and the PCR banks as part of our overall TPM discussion.
Okay, these are important concepts we've discussed earlier that our trusted platform has at its foundation some trusted component, a root of trust and the TPM serves is that root of trust component
well. The TPM provides to specific routes of trust. It provides the root of trust for storage, or RTs, and the root of trust for reporting are RTR. Additionally, the platform itself provides the root of trust, which is called the root of trust for measurement, or the RTM. So let's start here
the root of trust for measurement. The RTM is responsible for measuring the platforms integrity state and storing it into shielded locations. So what does that mean?
It means that as the platform boots, the RTM measures the integrity of the firmware and configuration files and whatever else happens to be configured to a measure.
And then the platforms root of trust for measurement reaches into the TPM and stores this data in the TPM root of trust for storage the RDS.
So it's stored in a special shielded or protected location called a PCR or platform configuration register. And don't worry, that sounds complex because it'll make sense soon.
It's important that the platform starts this measurement process when the boot process begins so that every step in the order, the step order of execution could be measured and stored.
We mentioned that the TPM provides two routes of measurement the root of trust for storage, the RTs and the router chest for reporting. The RTR,
the root of trust for storage is responsible for providing that protected storage toe hold the our teams, integrity measurements and the execution sequence.
The RTs provides confidentiality and integrity services. Specifically, the RTs is used to store measurement data and keys.
The measurement data is stored in shielded locations called a platform configuration register our PCR
keys. Specifically, it stores the storage root key which is used to store data safely, and external locations.
The root of trust for reporting. The RTR is responsible for reliably reporting information that resides in the RTs, so it provides at a station reports of integrity measurements so that third parties conveyor. If I the integrity of the platform,
we're going to spend several lessons on T, P M's and many of the things that we learn or will be used to support the TPM measured boot process.
So much of the knowledge we gain will help us understand more about that measured boot process. So let's quickly review with that process. Looks like so that you can visualize where we're gonna end up at
measured boot requires, Ah, hardware root of trust, which is the TPM chip.
And the process starts with the core root of trust for measurement. The RTM, which is the very first piece of code that's run the er TM is not measured, is just blindly trusted.
It measures the next step in this case, the BIOS.
And since that hash value of that measurement to the platform configuration register that PCR bank we've been talking about,
this process continues. Its each new section of code is measured and stored, and remote parties can can then request a report of those measurements to attest that the i o. T. Device booted in a safe manner.
Hopefully, now you can start to see the importance of establishing a root of trust for measurement to securely take measurements a root of trust for storage to securely store those measurements and a root of trust reporting to securely repair a report of those measurements. Well, that's it for this lesson. So what do we learn
when we started our trip into the mysterious world of trusted platform
modules and it's gonna be kind of a long trip.
We compare them to t es and we discussed the architectures, including protected capabilities and shielded locations. And finally we explore the TPM root of trust.
Up Next