Authenticating Consumable Products — Fakes Kill

By:Tom Moulton

How do you know whether that ink cartridge, air purification filter or medical test strip is really from the vendor on the sticker, or if you bought a cheap knockoff?  From an OEM perspective, how do you know your customers aren’t using those knockoffs, rather than something made or authorized by you? That guessing game can be eliminated with the addition of a simple, inexpensive crypto device in the design of your consumable products. The crypto device can be embedded in the consumable (client). When the consumable is installed or first used in the system (host), it is sent a challenge from the host. This challenge could be a fixed or random value. The host sends the challenge to the client, and the chip in the client calculates the response and sends the response back to the host. Upon receiving the response, the host compares it with the expected response. Only a consumable that provides the expected response can be used in the system. Sounds simple doesn’t it? This type of consumable authentication system is inexpensive and easy to implement.

In fact, a number of other configurations are available in these devices and can make the system even more secure. Some of these include: limiting the usage amount of the consumable attached to the system using a special key which can be used only for a limited number of times or by creating a unique key in the chip which is diversified based on its serial number. The benefit is that if an accessory is compromised, it would not affect other accessories because each accessory has its own unique key. And for the ultimate solution to consumable authentication, put a crypto chip in both the host and the client! The expected response can now be stored in hardware instead of embedding it in the host microprocessor code. This makes the response irretrievable for hackers who are attempting to circumvent the system. Isn’t a company’s reputation more important than the effort it would take to implement a simple solution like this? My suggestion is to only buy consumable products that use this type of hardware authentication solution.  Who knows, some day your life might depend on having the right consumable in a company’s product!

1:1 Interview with Michael Koster

---

Three-part Interview Series (Part 2)

---

Series 2 – IoT Toolkit and Roadmap

Tom Vu (TV):  What is in the roadmap for IoT Toolkit?

Michael Koster (MK):

The IoT Toolkit is an Open Source project to develop a set of tools for building multi-protocol Internet of Things Gateways and Service gateways that enable horizontal co-operation between multiple different protocols and cloud services. The project consists of the Smart Object API, gateway service, and related tools.

IoT Smart Object Structure

The foundation of the platform is purely bottom up, based on applying best practices and standards in modern web architecture to the problem of interoperability of IoT data models. I believe that the practice of rough consensus and running code results in better solutions than a top-down standard, once you know the basic architecture of the system you’re building.

To that end, I created a public github and started building the framework of the data model encapsulations and service layer, and mapped out some resourceful access methods via a REST interface. The idea was to make a small server that could run in a gateway or cloud instance so I could start playing with the code and build some demos.

The next step is to start building a community consensus around, and participation in, the data models and the platform. The IoT Toolkit is a platform to connect applications and a mixture of devices using various connected protocols.  It’s real power lies in its broader use, where it can span across all of our connected resources in industry, ranging from commerce, education, transportation, environment, and us. It’s a horizontal platform intended to drive Internet of Things more widely as an eventual de facto standard, built for the people who are interested in building out Internet of Things products and services based on broad interoperability.

IoT Applications Run on Cloud or On Gateway

We intend to create a Request For Comment (RFC), initiate a formal process for the wider Internet of Things platform and standards.  An community agreed upon process similar to the world wide web that we use today, based on rough consensus and running code, with RFCs serving as working documents and de facto standards that people can obtain reference code, run in their system to test against their needs, and improve and modify if necessary, feeding back into the RFC for community review and possible incorporation of the modifications.

The Internet of Things interoperability platform stands as an ideal candidate, leveraging the power of the open source community’s development process.  In turn, community involvement is taken to a new level, across many fields of discipline, and in many directions. Here is where we can get the most benefit of an agile community.  Crowdsource the development process based on principles of open communication and free of the need for participants to protect interests toward proprietary intellectual property.

We need to build the platform together meshed around the community of Makers, DIY, Designers, Entrepreneurs, Futurist, Hackers, and Architects to enable prototyping in an open ecosystem.  Proliferation then occurs; a diverse background of developers, designers, architects, and entrepreneurs have many avenues of participation. They can create a new landscape of IoT systems and products.

This broad participation extends to industry, academia and the public sector.  We are aiming for broad participation from these folks, build a global platform based on common needs. As a member of the steering committee, when I participated in the IoT World Forum, I heard from the technical leaders of enterprise companies (Cisco and others), research departments, and IoT service providers. They believe an open horizontal platform would be needed to enable applications that span across their existing vertical markets and M2M platforms.

Instead of a top-down approach, where people from corporations and institutions get together in a big meeting and put all their wish lists together to make a standard, we’re taking an overall bottom-up approach, bringing together a diverse community ranging from makers to open source developers, and entrepreneurs. Together with corporations, academia, and public sector, we all will participate in a very broad open source project to develop a platform that can be ubiquitous that everyone can use.

In many ways, this is modeled after the Internet and World Wide Web itself.  As we need to create a more formal standard, it will likely engage with the IETF and W3C. A good example is the semantic sensor network incubator project, which is an SSN ontology that describes everything about sensors and sensing. This enables broad interoperability between different sensor systems and platforms, based on common data models and descriptions. What we want to do is something similar to that, only on a more comprehensive scale and intended for the Internet of Things.

Tom Vu (TV):  Can you take us through a tour of the Data Object model importance and how it yields significance for simple and sophisticated connected devices?

Michael Koster (MK):

The Internet of Things today consists of many different sensor networks and protocols, connected to dedicated cloud services, providing access through smartphone and browser apps. It is rare for these separate “silos” to cooperate or interact with each other.

We abstract the complexity of sensor nets connecting devices and hardware by adding a layer of semantic discovery and linkage. This enables the sensors and actuators on disparate sensor nets to be easily combined to build integrated applications.

The way this works is using a few techniques. First, the different sensor nets are integrated through a common abstraction layer. This works a lot like device drivers in an operating system, adapting different devices and protocols to a common system interface. Only in this case, they are adapted to a common data model.

The common data model for sensor nets is based on the new IETF CoRE application protocol and sensor descriptions. This provides standard ways for common types of sensors to be discovered by their attributes, and standard ways for the data to be linked into applications, by providing descriptions of the JSON or BSON data structure the sensor provides as it’s output.

We use the W3C Linked Data standard to provide web representations of data models for sensor data and other IoT data streams. Linked data representations of IETF CoRE sensor descriptions are web-facing equivalents of CoRE sensor net resources. Linked data provides capabilities beyond what CoRE provides, so we can add functions like graph-based access control, database-like queries, and big data analysis.

Internet Smart Object

Internet of Things Applications are essentially graph-structured applications. By using Linked data descriptions of JSON structures and the meaning of the data behind the representation, we can create applications that link together data from different disparate sources into single application graphs.

Then we enable the platform with an event-action programming model and distributed software components. The common semantic language enables the data sources and software components to easily be assembled and make data flow connections. The result is an event-driven architecture of self-describing granular scale software objects. The objects represent sensors, actuators, software components, and user interaction endpoints.

Interent of Things with FOAT Control Graph

Tom Vu (TV):  Who and what companies should be involved?

Michael Koster (MK):

Whoever wants to participate in the building out of the Internet of Things. The people that use the infrastructure should build it out; the people who want to provide products and services based on interoperability, along with those who provide the backplane of thinking low power microcontrollers / microprocessors, connected sensors, and importantly the network infrastructure.

We want to enable all avenues of participation to allow corporations, academia, policy and standards makers, entrepreneurs and platform developers, makers, and DIY hackers all to be involved in building the platform as a community.

For corporations, we will provide an important role, to build a vendor-neutral platform for data sharing and exchange, an open horizontal platform that will allow the integration of what were traditionally vertical markets into new horizontal markets.

Anyone participating or expecting to participate in the emerging Internet of Things, Internet of Everything, Industrial Internet, Connected World, or similar IoT ecosystems initiatives, could benefit by participating in creating this platform. Companies that provide network infrastructure and want to build in value add can adopt this standard platform and provide it as infrastructure. Companies that want to provide new services and new connected devices that can use the IoT Toolkit to easily deploy and connect with existing resources could benefit.

All companies, organizations, and people that can benefit from an open Internet of Things are welcome to participate in the creation of a platform that everyone can use.

Tom Vu (TV):  How important is Open Source to Internet of Things evolution?

Michael Koster (MK):

I don’t see how the Internet of Things can evolve into what everyone expects it to without a large open source component. We need to go back to Conway’s law and look at it from both the system we’re trying to create and the organization that creates it. Interoperability and sharing are key in the system we want to create. It’s only natural that we create an open development organization where we all participate in both the decisions and the work.

Removing the attachment of intellectual property, changes the dynamics of the development team, keeps things engaged and moving forward solving problems. It’s important for software infrastructure projects like this to remove the barrier to cooperation that arises from the self-protection instinct around proprietary Intellectual Property, or even egoism associated with soft intellectual property, “my” code.

Instead, we turn the whole project into a merit-based system as opposed to being ego driven.  Rather than worry about guarding our property, we are motivated to solve the problems and contribute more to the deliverable. The limits to participation are removed and there is a more rapid exposure of intentions and goals. Engagement and innovation can rule in this environment of deep collaboration.

Tim Berners-Lee said that he was able to achieve the creation of the World Wide Web system because he didn’t have to ask permission or worry about violating someone’s copyright. We are creating the same environment for people who want to build our platform, and even for those who want to build their services and applications on top of the platform.

We are going to create the service enabled layer as open source as well so that any one of the companies can help proliferate the idea and everyone has influence and access to the development of the underlying IoT platform.  If it’s open source infrastructure and platform software, you can make a service on top of that software that can contain proprietary code. With our license, you can even customize and extend the platform for your own needs as a separate project.

Tom Vu (TV):  Describe your work with the EU IoT organization and how you are involved as a voice for the Internet of Things?

Michael Koster (MK):

I work with the IoT Architecture group within the overall EU Internet of Things project. The IoT-A group is closely related to the Future Internet project. They have an Architecture Reference Model describing different features one might build in an IoT platform, a sort of Architecture for Architectures. Since their process mirrors my own design process to a large extent, I found their reference model to be compatible with my own architecture modeling process.

They are conducting a Top-Down activity, stewarding the participation in the architecture and standardization model.  One of the ways I work with IoT-A is to use the Smart Object API as a validation case for the Architecture Reference Model. They are building the reference model top down, and we’re building the architecture bottom-up, based on a common expression of architecture relationships and descriptions.

I am also involved in advocating open source of IoT and building of local IoT demonstrator projects, educating around IoT, open data, etc. as well as user controlled resource access and privacy.  I am providing a voice for open source and open standards, into the standards movement going forward.

Here in the USA, there is not anything like what they have in Europe. Here the process will be to engage corporations and institutions and create a participatory structure that enables fair and open opportunity for influence and access to both the development process and the final products.

Tom Vu (TV):  How important is an open standard – building of an RFC in which all industries can agree upon ultimately serving to a wider scale factors of adoption and proliferation?

Michael Koster (MK):

To simply put it, the construction of a formal RFC is something that describes part of system.  A Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.  It is a process or evolution in achieving a more widely adopted standard.  The founders of the Internet created this process, and http, etc are all built using original RFC process from many years ago.

Through the Internet Engineering Task Force, engineers and computer scientists may publish discourse in the form of an RFC, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The IETF adopts some of the proposals published as RFCs as Internet standards.

If the IoT Toolkit platform becomes adopted, it may eventually be as many as 10-12 different RFCs, but it’s important to get people to agree on common first set.  This is the initial phase into a more pervasively used universal standard.  In fact, it’s sort of like a strawman platform.  It’s intent is to describe and collaborate, but also invoke and seek out broader participation…  We are at the stage of putting proposals together over the next few weeks and setting up meetings to talk to many people around collaboration and participation in building an Internet of Things platform.

We believe that an open standard platform for horizontal interoperability is key to achieving the promise of the Internet of Things. Everyone needs to be able to present and process machine information in machine understandable formats on the IoT, just as we humans enjoy commonly understandable web data formats and standardized browsers on today’s WWW. It’s important that developers be able to focus on solving problems for their clients and not waste resources on communication and translation.

Read Part Three to Learn More about Why IoT (Internet of Things) Matters?

Here are Part 1 and Part 2 of the Interview Series.

A Turnkey Security Solution for Accessories Authentication = $$$ in Your Pocket

By: Steve Jarmusz

An accessory could be really anything that works with a host or base system.  It could be a power charger, pair of speakers, cable, or as I mentioned, anything.   There are number of reasons why you would want to authenticate your accessories, to guard them against cloning and counterfeiting.  You may want to protect your brand or company’s reputation.  Apple does this with the “MFI” policy that they have initiated.  You might want to protect  customer safety.  Having a cloned surgical instrument or medical device that does not possess the same quality as the authentic product could be risky.   There have been a number of cases publicized  where the cloned product does not perform as well as the original.  A battery in cell phones and portable devices is one that comes to mind.  You can get really cheap knockoffs on E-Bay, but they may not last or have the storage capability as the OEM versions.  There are a number of authentication schemes that could be used to perform the accessory authentication sequence.  The most popular method that we have found is the Random Challenge Response method.

Atmel CryptoAuthentication

By adding an Atmel ATSHA204 CryptoAuthentication device to the host, the system is able to generate a Random Challenge for the client on the fly. In addition, by generating the challenge internally with the host’s ATSHA204 device, the response is unknown to the system, allowing the use of an unsecured processor without the threat that an attacker will be able to learn the system secrets. This dramatically limits the ability of an unauthorized device from producing the correct response.  You could also do this without a hardware device on the host, but the downside is less security.  Security is also very critical in many other applications. To learn more, check out this white paper on the technology and various use cases.

---

What can a hardware security chip do for you?

By: Maurice Jackson

When you embark on your next design, you should seriously consider what, in your design, is valuable—and, therefore, vulnerable to security breaches by thieves or hackers.   Make a list, check it twice, and I am certain that the Atmel CryptoAuthentication™ family of high-security hardware authentication devices can help.  The devices offer a flexible command set that allows use for many applications, including the following:

•  Anti-counterfeiting

Validate that a removable, replaceable, or consumable client is authentic. Example clients could be printer ink cartridges, electronic daughter cards, or other spare parts. It can also be used to validate a software/firmware module or memory storage element.

•  Protection for Firmware or Media

Validate code stored in Flash memory at boot to prevent unauthorized modifications (aka secure boot), encrypt downloaded media files, and uniquely encrypt code images to be usable on a single system only.

•  Session Key Exchange

Securely and easily exchange stream encryption keys for use by an encryption/decryption engine in the system microprocessor to manage such things as a confidential communications channel or an encrypted download.

•  Secure Data Storage

Store secret keys for use by crypto accelerators in standard microprocessors. It can also be used to store small quantities of data necessary for configuration, calibration, ePurse value, consumption data, or other secrets. Programmable protection up through encrypted/authenticated reads and writes.

•  User Password Checking

Validate user entered passwords without letting the expected value become known, map simple passwords to complex ones, and securely exchange password values with remote system.

•  Guaranteed Unique Serial Number

Each device has a unique 72-bit serial number.  The device can double as a storage for the unique serial number.

•  High-Quality Random Number Generator

The device includes an internal, high-quality random number generator (RNG).  As such, the device can be used as the source of an RNG.

Diversified Key with Random Challenge Response

By: Gunter Fuchs

Previously, in this space, we briefly discussed the four different authentication models that one can employ in an embedded design. Now, we’d like to take a deeper dive into the nuances of combining a diversified key model with the random challenge response model and the steps it takes in authenticating.

The following are the unique characteristics of this model:

• Each client has a unique serial number and a diversified key that are related by some cryptographic function
• A root key for the cryptographic function is stored on the host
• The hash algorithm is implemented on both the host and client
• A random number generator is required on the host

And the following outlines what is  going on inside the chips during the authentication process:

• The host reads the unique serial number from the client
• The host calculates the diversified key internally using the cryptographic function
• The host generates a random number for use internally and also sends it to the client as the challenge
• Both host and client perform the hash function using the diversified keys
• Host requests the calculated MAC from the client

Host compares the two calculated MACs to authenticate the client. Although complexity of implementing this “hybrid” increases, the benefit that comes with it is the added level of security.  Please stay tuned on this blog to learn more about tips and tricks on how you can secure your design or check out these useful resources on security.

A Deep Dive Into the Unique Challenge Authentication Model

By: Nelson Lunsford

Let’s take a closer look at the unique challenge authentication model, using an Atmel CryptoAuthentication IC, for protecting your design’s intellectual property (IP). At its most basic, the Atmel ATSHA204 CryptoAuthentication IC receives a challenge from a host system and a response is sent back to that host system. That challenge is combined with a secret key stored in the secure memory of the ATSHA204 using the MAC command. Then, the result or response is sent back to the host system. If the response is correct as determined by the host system, then the operation can proceed. What if a malicious entity (a hacker) had been monitoring the bus where the host and the client are exchanging the challenge and the subsequent response? If the challenge was the same value, then the response would be the same every time and the hacker would know that response without ever knowing the embedded secret in the ATSHA204 device. This would enable the use of a knock off product even when a company took steps to prevent it.

One simple solution to this specific problem would be to prevent the hacker from having prior knowledge of what the response is. If the challenge was different every time it is sent to the ATSHA204 IC, then the response would be different every time. A unique challenge does exactly that. Even if the hacker has a list of challenges and associated responses, they will not have the correct response or it will take too long to find it in a pre-compiled list.  A unique challenge is a perfect method for defending a system against replay-style attacks. If you are using a hardware security device on the host side, you would use the random number generator (RNG) within the hardware to generate the challenge, thus making the response completely random. However, many embedded systems do not have a high-quality RNG. An alternative to an RNG would be simply to use the date and the time of day combined. If a time of day is not available in the system, then a counter could be used. A counter with the combination of the serial number of the client device can be used. A counter does not have to increment by ‘1’; some multiplier function could be used instead.

Random Challenge / Response Authentication in Plain English

By: Gunter Fuchs

Working deep down in the guts (bits and bytes) of a computer, it becomes hard to explain concepts, once the electronic world has taken them over. I wondered about a simple way to explain authentication without referring to the world of computers, so that someone who isn’t savvy with technology can readily understand it.  Well, there is an authentication scenario in one’s modern day-to-day affairs that does not involve any computer (except if you consider the human brain to be one). This scenario is plain and simple: putting a signature on a piece of paper.

How can we describe a signing process in system security terms for authentication? Specifically, what has putting one’s signature on a contract or bill to do with “challenge / response authentication”? The analogy is quite simple. The challenge is the request by – say – the cashier to sign the bill. The response is your signature. That way, you prove that you are the person who owns the credit card. The cashier authenticates your signature by comparing it with the one on your credit card. In computer security terms, that means that the host (cashier) compares a stored response (your signature on the credit card) with the actual response (your signature on the bill). If the host (cashier) comes to the conclusion that both signatures are equal, it accepts the generator of the response as being authentic.

This scenario is quite insecure because someone can easily forge a signature. The reason in cryptographic terms is because this system can generate only one challenge / response pair. An adversary knows what the challenge will be, and if she has seen / copied the response (signature) only once, she can, after some practice, reproduce it relatively fast and easily. A way to improve the security in such a system is to increase the number of possible challenge / response pairs. An example in the online world is a list of question / answer pairs. Sometimes when you log in, a question pops up asking the name of your favorite pet, teacher, or band. Only you and the online host know the correct answer. Such a list increases the security of a system, but since this list is usually short, finding out the few answers by eaves-dropping is not a huge obstacle for an adversary. The advantage of such a short list of challenge / response pairs is that a human brain can manage it. But in a system where only computers play with each other, we can introduce much bigger lists. They are nowadays pairs  as big as 2^32. In such a system, with a huge number of challenge / response pairs, the host chooses one randomly. An adversary would now have to replicate this huge table, and once it has done that, search through this table for the challenge to find the correct response. Well, you could argue, why not? And how can an authentic client find the correct response in a feasible time? This issue is solved by introducing a cryptographic algorithm and a key into the system. By using a key and an algorithm, tables of challenge / response pairs don’t have to be generated and stored, but a host only has to generate a random number to “choose” a challenge. When the client receives this random number as a challenge, it combines it with a key using a cryptographic algorithm and sends the result back to the host (response). (The cryptographic algorithm “hides” the key so that an adversary cannot extract it from the response.) The host now performs the same calculation using the same key and compares the received response with its calculated one. If the two match—voila!—the host finds the client to be authentic.

With a system that incorporates the process of random challenge / response authentication, an adversary would have to monitor many, many (depending on the biggest number – “number space” – used in this system) authentication sequences between host and client and store them in a table. And after that, it would have to find the challenge in this table to come up with the correct response if it wants to pretend to be the authentic client. Finding it would practically take eternities, “would be infeasible” in cryptographic terms. The quality of the randomness of the random number is important, because the better the quality of the random number generator the less an adversary can predict the next challenge. If an adversary could predict the next challenge, he could search his table in advance.

random challenge response, cryptographic algorithm

Securing Your Design with the Fixed Challenge Authentication Model

By: James Tomasetta

Fixed challenge authentication is an easy way to add security to your product without the added expense of additional hardware to the host or client, interactive testing, or extensive software development.

Fixed Challenge Response

Fixed challenge authentication is the only authentication model that does not require a key or calculation on either the host or client.  With the fixed challenge model the host sends the same challenge every time authentication is needed and the client always responds with the same response.  By ensuring the same challenge and response are used both sides can have a pre-calculated version of the challenge response pair.

The major weakness in this model is that an attacker can monitor the bus and record the challenge/response pair and then use the recording to fool the system into validating a fake device.  This is known as a replay attack and is one of the easiest forms of attacks.  To counter this, the host can have a list of challenge/response pairs and randomly select from the list requiring the attacker to record multiple transactions on the bus prior to fooling the system.

Another key weakness in the system is that the challenge/response pairs need to be stored in memory, making them easy to extract from the host.  One solution to this is to add a hardware authentication device to the host.  Adding a hardware device like the Atmel ATSHA204 CryptoAuthentication IC allows the system to increase the level of security without the need to change any client device already in the field.

4 Different Authentication Models—Which One is Right for You?

By: Rocendo Bracamontes

Atmel’s ATSHA204 CryptoAuthentication™ device  allows four different ways to perform symmetric cryptographic authentication on a system:

• Fixed Challenge Authentication
  • Fixed Challenge Authentication is an easy way to add security to a product without the expense of added hardware to the host, interactive testing, or extensive software development. With Fixed Challenge Authentication, the client requires an ATSHA204 device programmed with secret keys. The host is able to use any number of pre-calculated challenge/response pairs to validate the presence of a valid ATSHA204 on the client side.

• Random Challenge Authentication
  • Random Challenge Authentication improves on the Fixed Challenge method by adding a Random Changing Challenge to each request. This feature enables the system to defend against replay-style attacks.
  •  By adding an ATSHA204 device to the host, the system can generate a Random Challenge for the client on the fly. In addition, by generating the challenge internally with the host’s ATSHA204 device, the response is unknown to the system, allowing the use of an unsecured processor without the threat that an attacker will be able to learn system secrets. This dramatically limits the ability of an unauthorized device from producing the correct response.

• Unique Challenge Authentication
  • Unique Challenge Authentication improves on the Fixed Challenge by adding a Unique Challenge to each request. This authentication feature enables the system to defend against replay-style attacks.
  • By adding an ATSHA204 device to the host, the system can generate a challenge for the client on the fly. This allows a unique challenge to be sent for every validation request.

• Diversified Key Authentication
  • This method includes the unique serial number of each ATSHA204 as part of the Cryptographic Authentication calculation. Diversified Key Authentication enables the host to identify the specific accessory that is trying to authenticate with it. This approach also enables the use of access lists (black lists) by the system.

With so many different options of authentication models, you can select the approach that best fits your design’s requirements, keeping your valuable intellectual property (IP) safe from malicious attacks or cloning.  To learn more about designing with the ATSHA204, including some design tips and tricks, check out this white paper.  Also stay tuned for further deep dives into each these models in the weeks to come.

Components to a truly secure system

By: James Tomasetta

In today’s increasingly connected world, the need for security is no longer just for communicating over the Internet, but is also needed to ensure that the user’s personal computer is free from malicious code.  In order to secure the user’s local computer, a root of trust  needs to be established, starting from the manufacturer of the hardware and continuing through the firmware and into the installed software.  The key components in securing this root of trust are a fixed or secured boot loader that is inherently trusted by the system and is used to start the authentication sequence, which can be implemented using many existing hardware security chips on the market, such as the ATSHA204 from Atmel.  The second key piece needed is a secure key vault used to store the keys used to sign different pieces of code loaded on the system back to their developers.  Once the code has been verified the boot ROM will start executing code and continue to repeat these steps until the system is fully booted.  Once the root of trust has been established for the system, the user can ensure that none of the code running on the system has been modified.