Trusted Execution Environment

00:00

Hi, I'm Matthew Clark, and this is less than 4.6 trusted execution environment.

00:07

In this lesson, we're going to introduce the trusted execution environment or t E.

00:13

We're going to take a look at its characteristics,

00:16

discuss the concept of security domains

00:19

and take a look a t e secure boot. Finally, we will conclude with a review of the I. O. T S F secure boot recommendations.

00:29

Ah, well designed T e will consist of the following security principles, Secure Butte

00:35

operating system, isolation application, isolation controlled access to hardware and a tamper resistant hardware root of trust that's capable of protecting cryptographic secrets and executing code securely.

00:52

In our previous lesson, we identified ways to make an integrated system on a chip secure by adding various hardware, roots of trust and technologies to it.

01:02

Software running on a non secure processor allows other applications or individuals with root access to investigate and manipulate the code and data running on the device.

01:14

A trusted execution environment addresses this vulnerability by enforcing confidentiality and integrity. During program execution,

01:23

the T divides the device and to trust those normal world in a secure world.

01:29

The normal world represents the non secure hardware and untrusted software on the device

01:36

and Secure World represents the protected hardware and trusted software.

01:41

Between them lies an isolation boundary that prevents trusted resource is from intermingling with either untrusted resource is or other trusted resource is

01:52

the isolation boundary creates thes security domains.

01:57

So this isolation boundary between the normal world and Secure World creates a dedicated security domain where trusted applications and data are isolated from untrusted applications outside of the trusted execution environment

02:15

and other trusted applications inside the trusted execution environment.

02:20

This means that secrets and private data that is processed or stored in one security domain cannot be accessed from another security domain.

02:30

This isolation also creates device stability because one application cannot impact the performance of another one.

02:38

A secure boot process ensures that the device starts in the secure state and that there's never a moment during the startup or launching of code in which the device is not secure. So how does that work? Well, one way is to create a transitive change of trust that starts with the root of trust code.

02:58

And remember, the root of trust code are the first few lines of code that air run

03:01

which are injected into a secure storage, usually during the manufacturing process.

03:07

What different routes of trust like T ee, TPM, HSM and ice have different implementations of a root of trust and different levels of root of trust strength. Each implementation also has a different way to handle the root of trust code.

03:27

Some implementations may trust the code inherently, meaning that

03:31

the code was injected during a trusted manufacturing process, so there's no need to further test it.

03:38

We find this in the T E and in the TPM

03:42

and the TPM caused the root of trust code. The C R T M R, the core root of trust for measurement

03:50

and the integrity of the ATM is never measured. It's just trusted,

03:55

and other implementations will verify the code before trusting it.

04:00

And we'll use the poems Private key to create a digital signature of the root of trust code

04:06

and then use it only in public. He to compare that signature so that the root of trust code is verified.

04:14

The dice does it a little bit different. The dice chip will always take a measure of the router trust code because this measure impacts the secure boot process.

04:26

But regardless of how the coat is treated, trusted or untrusted, the generic process for secure boot is the following.

04:33

The root of trust code is used to verify the next code that runs after it,

04:39

and the next line of code, um, is then used to verify the next line of code that runs after that and so on and so on.

04:48

Develop properly. Secure Boot establishes a mechanism for building trust in cases of device compromise or failure. The device can be programmed to either halt or reset itself by booting to a known good state.

05:03

So let's walk through the T e Secure boot process toe. Understand how this implementation handles it?

05:13

The trusted execution environment Secure Boot ensures the device boots into a trusted state.

05:19

The process begins with the boot Rahm, which is considered a trusted starting point because it's provisioned with the OM boot code and installed by the manufacturer.

05:30

The boot. Rahm verifies the boot loader image and signature before loading it.

05:35

If correct, the boot letter is allowed to execute

05:40

the boot loader then executes its code and before turning over control of the device to the trusted operating system. The boot loader ends verifies the trusted OS image and signature.

05:50

If correct, the trusted operating system is allowed to execute,

05:56

the trust is operating system would then launch trusted applications within the secure world and the rich operating system boot letter in the insecure environment within the normal world.

06:06

While some I O. T devices may have this level of complexity designed into them, many I OT devices do not have a fully developed operating system or allow for user installed applications.

06:18

Device OEM's may also use a trusted execution environment as, ah Harden execution area for the firmware to interface directly with hardware.

06:29

It's important Thio emphasize that the trusted execution environment doesn't create a strong of a root of trust is found in specialized hardware based roots of trust such as TPM or HS EMS.

06:43

Well known T es, um, include Intel's software guard extensions, Arms Trust zone, A, M, D. P. S P, and the risk of the multi zone

06:57

The I. O T. Security Foundation created several controls and its framework around secure boot and have a consolidated those controls. Recommendations here on this slide feel free to pause the video If you need more time to review these,

07:13

there's really top three that I consider the top three.

07:16

The first one is that the secure boot is enabled by default. The second one is that secure boot can be measured.

07:25

And the third one is that

07:26

data and credentials should be re initialized if the firm layer is updated.

07:34

Well, that's it for this lesson.

07:35

So what did we learn? Well, first, we took a brief trip into the mysterious world of trusted execution environments.

07:44

We started with their characteristics and moved on to the trust zones. And we talked about which world security domains live

07:51

part of my pond.