Trusted Platform Module Part 4

00:00

Hi, I'm Matthew Clark and this is lesson for 10 trusted platform module, Part four.

00:06

In this lesson, we'll talk about TPM states and the C R T M.

00:10

We'll also talk more about the PCR and measured boot and then we'll tie everything we've learned in the last four lessons together. So let's get started. OK, so let's do a quick review. Let's talk about certification authorities and the ownership process

00:25

within certification authorities. There's really two main that we've talked about. The trusted platform module entity or TPM. Me and the privacy. See A So let's talk about the TPM me it creates in signs of certificate called an endorsement credential, and the TPM E is usually the TPM manufacturer.

00:44

The science certificate provides assurance that the public key is properly tied to the private key

00:50

that the private KIIS securely held within the TPM and that the TPM properly follows the TCG standards.

00:58

The Prophecy C A is used for creation of at a station identity keys or ai cakes.

01:03

So the privacy see a receives a request from the TPM for the creation of an ai que and the TPM uses AI case as aliases for the endorsement key. To be able to establish identity,

01:17

the TPM sends its public endorsement key to the privacy. C A. And remember, the the endorsements key is only used for two reasons but taking ownership in creating a I cakes.

01:30

So then the privacy see a creates the ai Que, which gives third party assurance that the trusted components

01:38

PCR entries can be trusted to attest to the state of the trusted platform or, in other words, the TPM. PCR injuries can be trusted to test the state of the platform.

01:52

Let's talk about the take ownership process. This process creates the owner authorization data, which is like a password for the owner to use,

02:00

and it creates a storage root key. Both of these air on Leah's good as long as the owner has possession of the trusted platform.

02:10

So let's talk about TPM states. A TPM can exist in several states and some of these at the same time. The first state is if the TPM is owned or unknown.

02:21

Unknown is the default state. The TPM is shipped down.

02:23

If owned, then the take ownership process has been executed and all TPM operations are available. This requires an endorsement key pair from the TPM E and a secret owner authorization data that's set by the owner during the take ownership process.

02:40

The second state is if the TPM is activated or deactivated.

02:46

If activated, that all features air available. If deactivated, then this is similar to the disabled state. With the exception that states can change, it can switch to activated

02:58

and and you can change ownership. Of course, this requires the secret owner authorization data.

03:04

The third state is if the TPM is disabled or enabled.

03:07

If disabled, the TPM restricts all operations except the ability to report the TPM capabilities and the ability to accept updates to the P. C. R s.

03:19

If enabled, then all features air available proving providing that ownership has been established, meaning the TPM has to be in a owned state.

03:29

Now the TPM can exist in conflicting states where one state allows for an operation and the other state disallows it,

03:37

such as disabled and owned. Where disabled restricts all the operations and owned, enables the operations in these cases the most restrictive state winds.

03:50

And let's talk a little bit about the code root of trust for measurement. The C R T M.

03:54

We first introduced this concept in less than 4.7 when we learned about the measured boot process. It contains the instructions executed by the platform when it acts as the RTM. The route trust of for measurement,

04:08

the code root of trust for measurement, uses program code, which refers to the code that is used to start the device or, in other words, the firmware.

04:17

The court mom also adheres to the root of trust principal

04:23

as long as the program code is stored permanently in a tamper proof location than it was considered trustworthy. And there's no need to check the integrity of the code because it's installed securely during the manufacturing process.

04:36

However, the TPM can be configured to perform a self test on the RTM.

04:43

The C R TM can be stored either inside the TPM or outside the TPM in a secure storage associated with a typical boot operations such as a rahm. And this is most likely the location where we stored

04:57

Can the CRT M B changed with CRT M is injected during manufacturing and it can be immutable, meaning it's never changed after manufacturing, which is probably the preferred method, or it can be changed. But that would require a secure process to be built to change it

05:15

with appropriate cryptographic techniques in order to update it while in the field.

05:20

A router trust for measurement on RTM is different than the code router Trust for measurement. The C R T M

05:28

don't get confused by the 21 is the root of trust and the others program code.

05:33

So let's talk a little bit about platform configuration registers or PCR s. We've spoken so much about PCR s that they almost feels like an old friend.

05:42

The primary purpose of the PCR is to provide a method to cryptographic Lee record or measure the software state. Both the software running on the platform and the configuration data used by that software,

05:55

integrity measurements or metrics stored in these registers measure the integrity of any code from BIOS, tap locations and typically before the code is executed.

06:05

So I know the PCR stores data and the Ai Ki ai que signs the data in the PCR. But how does the PCR work? Well, that's a great question.

06:17

The PCR stores data and set registers and I'll show you the example of register in a minute

06:23

when a new calculation is made, the existing data and the register is not deleted. Instead, the register is extended through a process called and extend, which is a one way hash so measurements can't be removed.

06:36

The understanding that process is really beyond the scope of this class. Just know that PCR data is not deleted

06:43

was extended

06:45

and PCR stored in volatile Ram. There's there's a minimum of 12, 120 bit registers,

06:51

and PCR is removed when the power is removed from the TPM,

06:58

so registers must be reset whenever the system loses power or restarts.

07:02

If not, then the previous integrity metrics might remain in storage.

07:09

The TPM never passes judgment on the measurements

07:12

internally. It really doesn't know which measurements are quote good or bad,

07:17

much less if a process is mawr or less secure or trusted. All it knows is the values that it's measured.

07:26

It takes an added station process in order to pass judgment,

07:30

and T PM's can typically use of Shaw one or another hashing algorithm.

07:34

The PCR uses registers, the store values and the locations air pre defined by the implementation. So this is just merely an example.

07:45

Each location in the register can be programmed to record a specific function,

07:49

and the PCR axes a retainer. For those measurements, which represent a safe boot process, the values in the PCR again are not overridden but their extended.

08:01

In this example, you can see where the PCR registry zero through 15 or map to very specific functions. Where PCR zero is mapped to the BIOS code, PCR one is mapped, the BIOS, configuration and so forth and so on.

08:18

So here we are at the measured boot process. Ah, lot of what we've been talking about throughout the TPM lessons have laid the groundwork for our final topic.

08:28

This is where we ended our first lesson, and this is where we'll end our last lesson on this topic.

08:33

Measured boot built off the premise of a root of trust. It uses ah hardware root of trust.

08:39

The TPM component adds other routes of trust, which eventually enabled measured boot.

08:45

This process measures each of the components in the next stage of the boot process to verify that components integrity,

08:52

the overall purpose of a measured boot is to detect unauthorized software or configurations,

09:00

so let's talk about how it works. The TPM measured boot process begins when the device is booted. It starts with a core root of trust for measurement. The CRT M, which is the first piece of code to run it stored and protected secure storage either inside or outside of the TPM and a trusted boot block.

09:20

The C R T M is considered trusted because the code is injected during a trusted manufacturing process.

09:26

The RTM integrity is not measured by any external code.

09:31

The first action is that the RTM may conduct a self test, but this is not required.

09:37

When completed, the TPM will measure the BIOS and send the hash value to the platform configuration register the PCR bank.

09:48

The PCR Acts is a retainer for measurements which represent a safe boot process.

09:52

The values and the PCR not over written their extended

09:56

and each time a PCR is extended. Ah, long entry is made in the TCG event log.

10:03

The TCG event log allows you to reconstruct individually the PCR interests. So you have a method to see all the changes and to reconstruct changes from single entries.

10:13

The PCR can then verify that the measurements are correct.

10:18

If the measurements do not match, then an action can occur, such as a rollback procedure to return the module to the last known good before moving on to the next measurement step.

10:31

Remember, vendors have the ability to implement TPM anyway that they wished so long as they follow the TCG standard for TPM.

10:39

This process continues with the TPM measuring the boot loader next and then the next component and so forth with each preceding component in the boot chain measuring the following component until the devices successfully booted. So the CRT M measures the BIOS.

10:56

The BIOS measures the boot loader. The boot loader measures C. O S

11:01

and the OS measures the applications. Unlike a secure boot process, Ah, measured boot does not inhibit the usage of the system.

11:09

Insecure boot. If the component does not match, then the process halts.

11:15

The TPM process tracks the last known good state of the system.

11:20

Advanced implementations can roll back modules that have aberrations from previous measurements.

11:26

A ni O T devices ability to self heal by rolling back to the last known good state is a vital attribute especially when most coyote devices are deployed outside of a defined security perimeter.

11:39

Okay, so this is probably one of the longest lessons that we have so far, but it's important to pull it all together, and I'd like to end with this word cloud. It's really great. So here's all the all the different words that we've been using, and the amount of times that we've been using them

11:52

and I use a lot of resource is in my lessons. But sometimes a resource just absolutely stands out for its clarity and ability to really communicate a topic. And I'd like to call out Alan Tom Wilson, a professor at Virginia Tech. I have a reference to his paper introduction to the TPM and the reference section

12:11

Absolutely worth the read.

12:13

Please go read his paper.

12:16

If you ever get to take a class from him, I bet it is amazing.

12:20

I'd like to thank him for helping me personally understand several. These concepts and his writings, which I feel I've leaned liberally on, have really helped me learn this topic

12:31

again. Thanks for hanging in there.