 Now, let's explore how we use a root of trust to establish a chain of trust. To ensure product availability and integrity, all code should be authenticated before it is run. A great example of the chain of trust being implemented is the secure boot process. A secure boot process uses cryptographic functions to confirm the authenticity of code before allowing it to execute. A multi-stage boot process is one where each stage authenticates to the next, hence a chain of trust. The secure boot process is performed after a reset using a public key bound to the device. It is a stateful process for predictable behavior. This authentication process code should be stored in ROM or locked flash. It may also be performed by the root of trust. The code image being authenticated has to be signed using the code owner's private key. This private key must be kept safe. If exposed, it will allow hackers to sign their own boot code. Code images may also be encrypted. Protect your private signing key. The secure firmware update, like secure boot, we just discussed, is also a process, and it's a stateful process for predictable behavior. A file is downloaded containing the new firmware image and corresponding digital signature. This image is then authenticated using a public key stored in the device. If successful, the new firmware image is stored ready for use. The code image has to be digitally signed using the firmware owner's private key. The key must be kept safe. If exposed, it will allow hackers to sign their code. Code images should also be encrypted. Sensitive data should be encrypted when not being used. Provide access control to this data and restrict it to authorized persons and processes. Lockdown public keys and certificates as they don't need to be encrypted but only immovable. Ideally, cryptographically bound to the platform. Only allow their replacement through a cryptographic process. The key to success is protect your keys. Don't allow unauthorized access to keys. Secure communications is essential. Privacy from eavesdropping and interception. All devices should be uniquely identified and able to verify the identity and authenticity of other communicating devices. Make the use of established public key infrastructure standards. Use end-to-end encryption to protect data while in motion. Make use of established protocol standards like SSL and TLS and datagram TLS. Applications must handle sensitive data that must be protected. This requires some form of secure or trusted processing where sensitive data and associated code can be partitioned and kept separate from the main application code. Segmented processing requires manual separation of trusted and untrusted functions. Creating partitioned solutions requires a clear understanding of the software and the microcontrollers, memory protection unit, or firewall. Dual mode CPUs provide context switching between trusted and untrusted processing, which can simplify the partitioning and development of the secure processes. The most secure processing uses a secure processor or secure element like STs, STSafe. These provide the highest level tamper resistance for protecting cryptographic services and keys. Within any system, there are layers of functionality. Each layer has its own security processes, not necessarily relying on the capabilities of any other layer to protect its services or functionality. We see here an example of a layered system providing different services on each layer. To prevent a flaw in one layer's security being used to exploit another layer, these services should ideally be handled independently and siloed into different processing threads. For example, if your Wi-Fi password were to be discovered, your home surveillance cameras would not open to a hacker as its secure communications did not rely on Wi-Fi being secure. Debug ports represents an easy way to gain access to firmware, memory keys, and other sensitive information. Don't make it easy. Remove test headers and test points from your products. It's the first thing they look for, trust me. Analyze your firmware and remove any debug and native firmware loading interface capabilities. Finally, restrict access to production keys and only use test or dummy keys while the product is in debug mode. If the device has a lockable debug port, don't forget to lock it.