8 hours 10 minutes
Hi, I'm Matthew Clark. This is less than 4.2 foundations of trust, Part two.
In this lesson, we'll look at Rudy Trust further, and we'll discuss the associate ID, security services and trust elements.
We will review the principle of in mutability,
and we'll discuss the security concerns and life cycle planning for Richard Trust. So let's get started. Let's start with the quiz
when we use this term as it relates toe i o. T. Were stating that we have confidence in the identity and secure operation of a device. What is the term
encryption, ice cream trust or hardware?
The answer is trust
in terms of, ah, hardware root of trust. We're saying that we have confidence in the identity and secure operation of the device.
Encryption can provide a trust anchor, a term that will discuss later. And certainly encryption is a vital component of using a root of trust.
Hardware is also important to establishing routes of trust because hardware provides the strongest foundation for trust
and ice cream. Well, it just makes me hungry.
We've determined that a proper root of trust is established with hardware,
and this includes at a minimum, two things. Secure chips and storage
silicone chips, servas at foundation of trust.
And there's two general types of these chips. Ah fixed function, also known as a state machine and a programmable, secure microprocessor.
Secure storage is used to protect the initial code used to boot the device into a secure state. So we're talking about the first stage firmware,
and it also protects the keys, which are used to establish identity.
Additionally, roots of trust also provides security services
well, simply stated. If they didn't provide a service, then we wouldn't use them.
Thes security services include identification, authentication, confidentiality, integrity and measurement.
Combined. These services can also provide extended security services such as authorization
verification, secure updates, reporting and more.
The establishment of a root of trust requires additional trust elements.
At a minimum, they require that silicone based hardware root of trust, which could be a TPM and HSM, or dice, or others
secure storage. And that's generally located storage within the chip or a dedicated read only memory
cryptographic functions, including asymmetric symmetric hashing nonsense, is true. Random number generators,
immutable code, which will touch on that topic in a moment,
isolated environments and many times This refers to a trusted execution environment or a T E
and Secure boot, which boots the device into a verified secure state
in mutability, is to find its an object whose state cannot be modified after is created.
I love this picture because, at least for me, it symbolizes the properties of mutability.
It's hard for software by itself to serve as a foundation for root of trust. Because software does not provide a mechanism to establish in mutability.
Remember, not all in mutability is good. For example, Hard coating immutable credentials into a device is almost worse than not having any credentials because it gives a false state of security.
And making all device code and applications immutable would inhibit the secure update process
and prevent vulnerabilities from being patched.
Remember, in our previous lesson, when I asked if it would be wise to put all of the device software inside of a trusted computing base,
we wouldn't want to do that because we need the software to be mutable, changeable and up datable. If that's even a word
both for adding and modifying features and device capabilities as well as addressing vulnerabilities and Olaf Top 10 problems
one more slide on this topic Before we move on,
let's assume that the OM really wants to develop a software based root of trust because of X, y or Z reason. Regardless of what the reason is, it will generally be cost
as a sip. So what are you going to advise the business as potential security issues that they should expect?
Well, first, the business We need to understand the risk of losing control of the device itself.
If threat actors can successfully attack the first stage boot loader, then they can subvert the colonel or replace it.
This would provide Attackers with the highest level of privilege on the device and the ability to subvert all other layers.
It also gives the attacker the ability, the attributes of persistence.
Attackers would be ableto live on the system even after the OS and applications are re installed by the user. Since they've had access before the operating systems and applications load.
Second, the business would need to understand the risk of losing control of the boot process.
If a threat actor gains control of the device,
then do you lose control of the firmware and you've lost control of the device.
The threat actors would be able to bypass all the other security controls, such as
they would be able to control how the device boots,
what operating system. The device boots, what applications the device loads and how the device operates
and damage can be severe. Attackers could break the devices, be a ransom where
they could steal user data.
They can watch you through your cameras or speak to you through your TV s
and, of course, my favorite. They can welcome the device to the botnet,
since most of the decisions seem to be based off a cost. The sip so should remind the business of the cost of lawsuits or failure to follow regulations or the damage to company reputation when they become the next Internet meme. And that's not to mean that the
sip so should really revel or use, you know, fear and uncertainty and doubt. It's just a matter of pointing out that there's a cost to everything,
and that extra dying per device for a TPM really isn't that expensive compared to those possibilities.
So let's take a look at rid of trust throughout the life cycle.
Reader just is important to consider throughout the entire life cycle. The device and the sip so should work with device engineers to address the issues across the entire life cycle, starting with the design cycle
in which the OM defines requirements based on purpose and the risk profile.
The use of a framework to identify the required and optional security controls
and choosing hardware based on requirements and on environmental restrictions
and off course using a risk based approach is they do that
and then designing for security based on that risk profile. Using the guidelines and best practices found in the framework
in the manufacturing stage, they should work to create a process to securely established a root of trust as the product is created,
ensuring that appropriate steps were taken to protect secrets during that manufacturing process.
Paying careful attention to how the device identity is injected into the device
in the commissioning stage, ensuring the device can be securely provisioned, relying on certificate based authentication and during the devices service life, ensuring that secure boot cannot be disabled or turned off
securely. Managing the certificate life cycle, such as activities like managing life cycle of the keys themselves,
dealing with certificate expiration and renewal and ownership changes
ensuring that the firmware is immutable or or Onley mutable when consented to by the device owner and providing secure over the air updates ensuring that updates themselves. Do not lessen security and don't change the security settings which have been selected by the end user
and ensuring firmware updates are cryptographic. Lee signed and sent over a secure channel.
Finally, during the end of life, ensuring that the digital certificates are revoked and customer data is securely wiped.
Well, that's it for this lesson.
In this lesson, we discussed the root of trust. We learned about immutable code
we outlined to the root of trust elements and services and how one enables the other and discussed security concerns. And we discovered how root of trust flows throughout the entire device life cycle.
I'll see you next time