Module 14 Review

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

8 hours 10 minutes
Video Transcription
Hi, I'm Matthew Clark. This is less than 4 14 module for review.
We've gone through a lot of technical details in the last several lessons, so I think a review is important. In this lesson. We will review foundations of Trust, the trusted execution environment, the trusted platform module, the hardware security module and the device identity and device satis station. So let's get started
in our foundations of trust section. We reviewed Microsoft seven properties of highly secure devices, which included starting with the hardware root of trust,
having a small, trusted computing base using defense in depth and compartmentalization, using certificate based authentication and planning for renewable security and using failure reporting.
We also learned that it's vital to maintain trust throughout the device life cycle
and that identification is a requirement for authentication
and enablers of trust included cryptography, secure storage, keeping trusted from untrusted and using immutable code
in our trusted execution environment sections. We learned that T E is a secure, isolated environment within the microcontroller that separates trusted from untrusted via hardware, and you cannot access the secure world data from the normal world or from other secure worlds.
A T E includes the use of
a root of trust, immutable code, trusted boot loader and runtime isolation,
and it provides security services such as confidentiality, privacy and integrity.
We also learned that the T idea is implemented by many vendors, but the global platform developed a standard for it. The trusted execution environment is compatible with other standards, such as the TPM,
and examples of well known T es are Intel's software, guard extensions and arms. Trust them.
We learned about the T E secure boot process that it ensures the device boots to a trusted state. The process begins with the boot Rahm, which is considered a trusted starting point because it's provisioned with the OEM's boot coat and installed by the manufacturer,
the boot. Rahm verifies the boot litter image and signature before loading.
If correct the boot letters allowed to execute the boot letter, then executes his code and, before turning over, control the device to the trusted operating system. The boot letter verifies the trusted operating system image and signature.
If correct, the trusted OS is allowed to execute the trusted OS, then launches trusted applications within the secure world and the rich operating system Boot letter in the insecure environment within the normal world.
We also learned about the trusted platform module that it provides a root of trust. The TPM is physically attached to the device. It's either there or it's not. You can't add it afterwards. The purpose of the TPM is to secure the platform. If you remove the secure component from the platform,
you'll not be able to decrypt data.
It's a standard developed by the trusted computing group, or TCG, and you could read the standard to know how it should work. Companies can build on the standard, but it has a certain way that it should be designed. The TPM includes use of hardware, roots of trust, encryption and immutable code and provide security services such as measured boot
remote at a station,
user authentication and full disk encryption.
HS, EMS and TPM provides secure encryption capabilities by storing and using. In our sake,
TPM provides a measured boot process,
which starts with the core root for of trust for measurement. The Siart mom.
This is the first piece of code that has run its stored and protected secure storage inside or outside of the TPM and a trusted boot block
the Cartman is considered trusted, its integrity is not measured by any external code,
and the code is injected Term manufacturing
measure boots First action is to see. RTM may conduct a self test, but this is not required
if it does. When completed, the TPM will measure the BIOS and send a hash value to the platform configuration register or the PCR bank.
The PCR axes a retainer for measurements which represent a safe boot process.
The values in the PCR are not overridden. They are extended
each time the PCR is extended. A log entry is made in the TCG event Log
TCG Event logs allow you to reconstruct individual PCR entries so that you have a method to see all the changes and reconstruct changes from single entries.
The PCR will then verify that the measurements are correct.
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 and move to the next measurement step.
This process continues with the TPM measuring the boot loader next and then the next component and so forth with each proceeding component in the boot chain describing the following component until the device has successfully booted the CRT M measures. The BIOS, the BIOS measures the boot loader.
The boot letter measures Theo S
and the OS measures applications.
Unlike a secure boot process, a measure boot does not inhibit the usage of the system.
We also learned about HSM hardware security modules. We learned that they're not a standard, however. They are subject to the Phipps 1 40 dash to security requirements for cryptographic modules,
usually their inner workings. The protection techniques and methods are not fully disclosed. You cannot look up to see how one works as you can. The TPM or Dice
HSM is generally focused on hardware security and come in many different sizes, such as the yuko USB dongle to rack mounted external devices and also cards that could be plugged into motherboards.
HS EMS can be a large, secure element, with protections focusing on the hardware security side and can operate faster than T PM's. At least the rack mounted ones can
or HSM could be added to a system
unlike a TPM, it doesn't have to be physically connected. Cloudhsm Zahra great example of this principle
in the main purpose of an HSM is to ensure key material cannot be extracted and they also handle the functions for digital signatures.
While studying HSM, we also reviewed the secure boot process and this is a general secure boot
to set up a secure boot properly, the O. E. M will use its private key to create a digital signature of software that will be used by the device during the boot process.
During the manufacturing process, thes signatures, along with the first stage boot loader code, are stored on the device hardware and non rideable protected memory.
This process creates a root of trust for the device. During boot, the device loads the trusted code stored in the manufacturing process.
The cryptographic system then uses the public key and the BIOS to compare the signature, the second stage boot loader with the second stage boot letter code. If the comparison matches, then the system will determine that the second stage boot letter could be trusted and the boot process moves forward to the next stage.
This signing a verification continue throughout the boot process, from the firmware and boot letter to the colonel on modules creating a secure chain of trust.
So to understand ice, let's look at what it does not provide. It does not provide secure boot. There's no stopping the boot process if dice runs across unexpected code.
And there's no persistent, isolated environment, either. We're not gonna find elements of a T E present,
and there is no specific measure. Boot. While dice does measure the boot code, it doesn't provide a measure boot in the same way a TPM does.
And Ice is considered a lightweight root of trust.
But it does not form the hardened security of NHS A. It's not gonna pass 1/5 certification, and we won't be able to use it to secure banking transactions either.
So this is the dice process. The first step in the process begins by taking a measure of the first beatable code,
this computer measure and the U. D s or passed through a one way function to create a compound device identifier. A CD I.
The 500 is then used as the basis for the device identity.
The CD is important because this entire concept is dependent upon dice, unconditionally generating the correct C D. I for layer zero,
the CD for layer zero becomes the next link and the dice chain of trust
Hardware latching mechanism is then engaged to prevent read access to the U. D. S. And this prevents the U. D S remain access maliciously later on.
The U. D s is then securely erased from all registers, caches and memory.
The CD is then passed to the next layer of secure boot process, along with control with the boot process.
Output from lower layers always provides input to the next higher layer. Example. Layer zero to layer one higher layers. Never provide him. Put the lower layers example layer to back toe layer one.
Each subsequent layer
receives a secret from the proceeding layer measures the next layer and generates a new secret for the next layer.
Well, that's it for this lesson and this module and this lesson. We reviewed the foundations of Trust and T e TPM, HSM and ice. I'll see you next time
Up Next
IoT Product Security

This course will focus on the fundamentals of how to set up a functioning IoT product security program from the perspective of a company that designs, manufactures, and sells IoT and IIoT devices for consumer or industrial use.

Instructed By