System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

PDF

System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

Hardware trust

Want to summarize with AI?

Log in

Details hardware trust principles, including hardware-anchored roots of trust, integrity checks with chip guard, attestation processes, and required service requests for hardware validation failures, with instructions for verifying hardware trust and PCR quotes.


Hardware trust is a trustworthy systems foundation that

  • anchors system integrity in hardware

  • uses immutable trust components, and

  • supports later software and runtime trust validation.

Additional reference information

Trust in the hardware is enabled through specific components within the Cisco 8000 Series Routers that ensure the integrity and reliability of the system.


Hardware-anchored root of trust

A hardware-anchored root of trust is an immutable hardware trust component that

  • starts the chain of trust at boot time

  • verifies each boot stage before execution, and

  • helps prove that device hardware and software are authentic.

The first component in implementing a trustworthy system is to enable trust in hardware.

Because software alone cannot prove a system's integrity, truly establishing trust must also be done in the hardware using a hardware-anchored root of trust. Without a hardware root of trust, no amount of software signatures or secure software development can protect the underlying system if the underlying system is compromised. To be effective, this root of trust must be based on an immutable hardware component that establishes a chain of trust at boot time. Each piece of code in the boot process measures and checks the signature of the next stage of the boot process before the software boots.

A hardware-anchored root of trust is achieved through:

  • Anti-counterfeit chip: All modules that include a CPU, as well as the chassis, are fitted with an anti-counterfeit chip. This chip supports co-signed secure boot, secure storage, and boot-integrity-visibility. It ensures the device's software and hardware are authentic and prevents tampering or unauthorized modifications. It also enforces strong authentication and access control policies to protect sensitive data.

  • Secure Unique Device Identifier (SUDI): An X.509 SUDI certificate installed at manufacturing provides a unique device identifier, enabling anti-counterfeit checks, authentication, and remote provisioning. The SUDI is generated using the device's unique hardware identifier—such as its serial number or MAC address—and a securely stored private key. This ensures that each SUDI is unique and cannot be easily duplicated or forged. When a device attempts to connect to a network, the network uses the SUDI to authenticate the device, ensuring only trusted devices are permitted access.

  • Secure JTAG: A secure JTAG interface is used for debugging and downloading firmware, protected by asymmetric-key-based authentication and verification protocols. This prevents attackers from modifying firmware or stealing confidential information. Secure JTAG includes hardware and software measures, such as encryption and authentication protocols for securing communications, and access control policies to restrict interface access to authorized users.

Additional reference information

Hardware-anchored roots of trust are enabled by default on Cisco 8000 Series Routers.


Verify hardware trust status

Confirm whether hardware-anchored root of trust is enabled and integrity is verified in the router.

Hardware-anchored root of trust is enabled by default on Cisco 8000 Series Routers. Verifying the hardware trust status ensures device integrity and compliance.

Before you begin

Confirm that the router is running a supported Cisco IOS XR release and platform variant.

Procedure

Display hardware integrity status.

Example:

Router# show platform security integrity hardware
Wed Apr 17 11:19:03.202 UTC

+--------------------------------------+
   Node location: node0_RP0_CPU0
+--------------------------------------+
TPM Name: node0_RP0_CPU0_aikido
Uptime: 52050
Known-good-digests:
Index   value
  0     hh4jzFBlxSGHZ4hKqnC2FEjqHg4tpx/chZ7YcTwLCco=
observed-digests:
Index   value
  0     hh4jzFBlxSGHZ4hKqnC2FEjqHg4tpx/chZ7YcTwLCco=
PCRs:
Index   value
  15    Dl1BGskyzeJ1LNYKuZK8Qqllwkth0ru+0xWydL9YMdc=

The output provides information about the node location, TPM name, uptime, known-good digests, observed digests, and PCRs. Verify that the values match and trust is enabled for the hardware.

The command output confirms the hardware integrity status for the node, indicating whether the hardware trust is enabled.


How chip guard hardware integrity checks work

Chip guard is designed to address hardware supply chain risks where attackers might replace ASIC or CPU chips in a Cisco router with counterfeit or malicious units. Compromised chips threaten performance, reliability, and security, potentially introducing hidden vulnerabilities. By validating chips before deployment, chip guard helps preserve hardware integrity.

Summary

The key components involved in the process are:

  • Application Specific Integrated Circuit (ASIC): Executes critical hardware operations, such as scanning the egress queue for error causes.

  • CPU chip: Runs the router’s operating system and manages core processing.

  • TAm chip with Imprint and Observed databases: Stores and compares SHA-256 chip ID hashes to verify authenticity during boot.

Chip guard hardware integrity checks help ensure Cisco routers contain authentic ASIC and CPU components during secure boot, protecting against supply chain attacks and counterfeit chips.

Workflow

These stages describe how the chip guard hardware integrity checks work.

  1. Router manufacturing: The TAm chip is programmed with SHA-256 hashes (digital fingerprints) of the CPU and ASIC chip IDs, stored in the Imprint database (Imprint DB). These values remain immutable for the router’s lifetime.
  2. Router deployed and powered up: During the secure boot process, the chip guard feature recomputes the SHA-256 hashes of the CPU and ASIC chip IDs, creating the Observed database (Observed DB) within the TAm chip.
  3. Comparison of Imprint and Observed databases:
    • If the Imprint DB and Observed DB match, chip guard validates the hardware as authentic and allows the router to continue booting.

    • If the databases do not match, chip guard identifies a counterfeit chip and halts secure boot. A warning message is displayed, indicating that supply chain integrity has been compromised.

Result

Chip guard ensures that only genuine ASIC and CPU components are used in the Cisco router. If counterfeit chips are detected, secure boot is halted, preventing compromised devices from entering the network.

Stages of chip guard implementation

The table shows the various stages through which chip guard is implemented on the router.

Table 1. Table

Stage

Process/Action

Result

1. Router Manufacturing

SHA 256 hashes of the electronic chip IDs of both the CPU and ASIC are programmed in the TAm chip and stored in a database known as Imprint DB.

The Imprint DB inside the TAm chip contains the SHA 256 hashes, which cannot be modified during the router’s lifetime.

2. Router Deployed in the Field and Powered Up

During the secure boot process, the chip guard feature recomputes the SHA 256 hashes of the electronic chip IDs of both the CPU and ASIC and creates a database known as Observed DB.

The Observed DB values are stored inside the TAm chip.

3. Comparison of Imprint DB and Observed DB

DBs match

The router continues to boot. Depending on the capability of the underlying router, the chip guard feature validates either the CPU, ASIC, or both.

DBs do not match

The router notifies that either the CPU or ASIC is counterfeit, and the secure boot process halts. A message is displayed on the console about the chip guard validation failure.


Attestations

Attestations are integrity validation mechanisms that

  • let external verifiers request device integrity quotes

  • use TAm-signed PCR quotes and audit logs, and

  • protect verification using nonces and router-specific attestation keys.

Attestations enable external verifiers to check the integrity of the software running on the host. Implementing this feature on Cisco hardware helps you validate the trustworthiness of hardware and software for network devices.

Once a router is up and running, you can send a request to an external verifier. The external verifier requests an attestation quote from the router. The TAm chip outputs the PCR quote and audit log, signing the quote using an attestation private key unique to that router, and responds to the verifier. The verifier uses Cisco-provided KGV hashes and the Attestation Public Certificate to verify the attested PCR quotes and audit logs. This verification is protected against repeat attacks using a nonce. Additionally, verification ensures attestation is specific to a particular router by using attestation key pairs. These attestation key pairs are unique to each router and ensure attackers cannot tamper with router hardware, boot keys, boot configuration, or running software.


Verify attestation PCR quotes

Ensure that hardware integrity is maintained by checking the PCR quote and its associated signature.

Use this task to verify the hardware integrity proof exposed by Cisco IOS XR platforms via attestation PCR quotes. This check is typically performed as part of security audits or compliance initiatives.

Before you begin

Confirm that the router is running a supported Cisco IOS XR release and platform variant.

Procedure

Use the show platform security attest pcr 0 trustpoint ciscoaik nonce 4567 location 0/RP0/CPU0 command to display the attestation PCR quote.

Example:

Router# show platform security attest pcr 0 trustpoint ciscoaik nonce 4567 location 0/RP0/CPU0
Thu Apr 11 05:44:10.808 UTC
Nonce: 4567

+--------------------------------------+
   Node location: node0_RP0_CPU0
+--------------------------------------+
Uptime: 1198700
pcr-quote: /1RDR4AYACCkyXSBYFKZw5Nurif7DYQRMrBTg6q91heoKFZW0kp0FQACRWcAAAAABX5fDQAAA97/////AQAAACQAAAALAAAAAQALAwEAAAAgrE798LlOkKp1kryIv50kG0/V461IQutuSVgCUwjG8q4=
pcr-quote-signature: mC8oPWYzgSTge31DLXCs/Ez7BRKsZyDVb4auuhJagWHa3aHSa9eMf34Y/FMuTitjeAhcs---<truncated>---dJYpsPKMGkcro1IquTnaD1gKIH+Gh4QBewdNky3Igiw==
pcr-index       pcr-value
  0             sL3H+Em2xzxXrNUoDF+kC47IXxN4V/d/7hYUXApXNoY=

Proof of hardware integrity is recorded in the TAm as part of Chip Guard.

Note

The same data is also available through NETCONF for a remote attestation server: Cisco-IOS-XR-remote-attestation-act.yang.

Hardware integrity is verified. You have obtained the nonce, PCR quote, quote signature, and PCR value, confirming the platform's attested state.


Requirement: hardware validation failure service request