3.1.2. Secure the Devices and Their Credentials¶

ID	Priority	Best Practice
BP 3.1.2.1	Required	Use a separate hardware or a secure area on your devices to store credentials
BP 3.1.2.2	Highly Recommended	Use a trusted platform module (TPM) to implement cryptographic controls
BP 3.1.2.3	Recommended	Use protected boot and persistent storage encryption

Architecture Notes - BP 3.1.2.1 - Use a Separate Hardware or Secure Area on your Device To Store Credentials¶

A ‘secure element’ is any hardware feature you can use to protect the device identity at rest. Secure storage at rest helps reduce the risk of unauthorized use of the device identify. Never store or cache device credentials outside of the secure element. Use a secure network, such as using TLS, or a secure manufacturing facility, when transmitting credentials to the secure element. Securely handling a device’s identity helps ensure that your hardware and application are resilient to potential security issues that occur in unprotected systems. A secure element provides encryption of private information (such as cryptographic keys) at rest and can be implemented as separate specialized hardware or as part of a system on a chip (SoC).

Recommendation 3.1.2.1.1 - Use tamper-resistant hardware that offloads the security encryption and communication from the IoT application Device credentials always reside in a secure element, which facilitates any usage of the credentials. Using the secure element to facilitate the use of device credentials further limits the risk of unauthorize use. As an example, AWS IoT Greengrass supports using a secure element to store AWS IoT certificates and private keys.

See the following for more information:

AWS IoT Greengrass: Hardware security integration

Recommendation 3.1.2.1.2 - Use cryptographic API operations with the secure element hardware for protecting the secrets on the device

Ensure that any security modules are accessed using the latest security protocols. For example, in Amazon FreeRTOS, use the PKCS#11 libraries for protecting secrets. See the following for more details:

Amazon FreeRTOS: corePKCS11 library

Architecture Notes - BP 3.1.2.2 - Use a Trusted Platform Module to Implement Cryptographic Controls¶

Generally, a TPM is used to hold, secure, and manage cryptographic keys and certificates for services such as disk encryption, Root of Trust booting, verifying the authenticity of hardware (as well as software), and password management. The TPM has the following characteristics:

TPM is a dedicated crypto-processor to help ensure the device boots into a secure and trusted state.
The TPM chip contains the manufacturer’s keys and software for device encryption.
The Trusted Computing Group (TCG) defines hardware-roots-of-trust as part of the Trusted Platform Module (TPM) specification.

A hardware identity refers to an immutable, unique identity for a platform that is inseparable from the platform. A hardware embedded cryptographic key, also referred to as a hardware root of trust, can be an effective device identifier. Vendors such as Microchip, Texas Instruments, and many others have TPM-based hardware solutions.

See the following for more information:

The Internet of Things on AWS – Official Blog: Using a Trusted Platform Module for endpoint device security in AWS IoT Greengrass

Recommendation 3.1.2.2.1 - Perform cryptographic operations inside the TPM to avoid a third party gaining unauthorized access

All secret keys from the manufacturer required for secure boot, such as attestation keys, storage keys, and application keys, are stored in the secure enclave of the chip. For example, a device running AWS IoT Greengrass can be used with an Infineon OPTIGA TPM.

Recommendation 3.1.2.2.2 - Use a trusted execution environment (TEE) along with a TPM to act as a baseline defense against rootkits

TEE is a separate execution environment that provides security services and isolates access to hardware and software security resources from the host operating system and applications. Various hardware architectures support TEE such as:

ARM TrustZone divides hardware into secure and non-secure worlds. TrustZone is a separate microprocessor from the non-secure microprocessor core.
Intel Boot Guard is a hardware-based mechanism that provides a verified boot, which cryptographically verifies the initial boot block or uses a measuring process for validation.

Recommendation 3.1.2.2.3 - Use physical unclonable function (PUF) technology for cryptographic operations

A PUF technology is a physical object that provides a physically defined digital fingerprint to serve as a unique identifier for an IoT device. As a different class of security primitive, PUFs normally have a relatively simple structure. It makes them ideal candidates for affordable security solutions for IoT networks. Generally, a hardware root of trust based on PUF is virtually impossible to duplicate, clone, or predict. This makes them suitable for applications such as secure key generation and storage, device authentication, flexible key provisioning, and chip asset management. For example, refer to AWS Partner Device Catalog , that has various device solutions with PUFs such as LPC54018 IoT Solution by NXP.

Architecture Notes - BP 3.1.2.3 - Use Protected Boot and Persistent Storage Encryption¶

When a device performs a secure boot, it validates that the device is not running unauthorized code from the filesystem. This helps ensure that the boot process starts from a trusted combination of hardware and software, and continues until the host operating system has fully booted and applications are running.

Choose devices with TPM (or TEE) for new deployments. Secure boot also ensures that if even a single bit in the software boot-loader or application firmware is modified after deployment, the modified firmware will not be trusted, and the device will refuse to run this untrusted code.

Full disk encryption ensures that the storage and cryptographic elements are secured in absence of a TPM or secure element. The disk controller needs to ensure that all read accesses to the disk are transparently decrypted at-runtime.

Recommendation 3.1.2.3.1 - Boot devices using a cryptographically verified operating system image

Use digitally signed binaries that have been verified using an immutable root of trust, such as a master root key (MRK) that’s stored securely in a non-modifiable memory, to boot devices.

Recommendation 3.1.2.3.2 - Create separate filesystem partitions for the boot-loader and the applications

As an example, configure the device boot-loader to use a read-only partition, and applications to use a separate writable partition for separation of concerns and reduce the surface area of the attack.

Recommendation 3.1.2.3.3 - Use encryption utilities provided by the host operating system to encrypt the writable filesystem

For example, use crypt utilities for Linux such as dm-crypt or GPG, and use BitLocker or Amazon EFS for Microsoft Windows.

Recommendation 3.1.2.3.4 - Use services that enable you to push signed application code from a trusted source to the device

You can use AWS IoT Jobs to push signed software binaries from the cloud to the device. For microcontrollers using Amazon FreeRTOS, ensure that the firmware images are signed before deployment.

3.1.2. Secure the Devices and Their Credentials¶

Architecture Notes - BP 3.1.2.1 - Use a Separate Hardware or Secure Area on your Device To Store Credentials¶

Architecture Notes - BP 3.1.2.2 - Use a Trusted Platform Module to Implement Cryptographic Controls¶

Architecture Notes - BP 3.1.2.3 - Use Protected Boot and Persistent Storage Encryption¶

Additional Resources¶