Enable Trust in Hardware
The first component in implementing a trustworthy system is to enable trust in hardware.
Because software alone can’t 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 from becoming 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, which supports co-signed secure boot, secure storage, and boot-integrity-visibility. The chip ensures that the device's software and hardware are authentic and haven’t been tampered with or modified in any way. It also helps to prevent unauthorized access to the device's sensitive data by enforcing strong authentication and access control policies.
-
Secure Unique Device Identifier (SUDI): The X.509 SUDI certificate installed at manufacturing provides a unique device identifier. SUDI helps to enable anti-counterfeit checks along with authentication and remote provisioning. The SUDI is generated using a combination of the device's unique hardware identifier (such as its serial number or MAC address) and a private key that is securely stored within the device. 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, and ensure that it’s authorized to connect. This helps to prevent unauthorized access to the network and ensures that only trusted devices are allowed to connect.
-
Secure JTAG: The secure JTAG interface is used for debugging and downloading firmware. This interface with asymmetric-key based authentication and verification protocols prevents attackers from modifying firmware or stealing confidential information. Secure JTAG typically involves a combination of hardware and software-based security measures. For example, it may include the use of encryption and authentication protocols to secure communications between the JTAG interface and the debugging tool. It may also involve the use of access control policies and permissions to restrict access to the JTAG interface to authorized users only.
 Note |
Hardware-anchored root of trust is enabled by default on Cisco NCS 540 Series routers. |
Verification
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=Secure Hardware for Strong Cryptography
All Cisco IOS XR7 supported-platforms ships with a non-tamperable Trust Anchor module (TAm) in the hardware.
TAm houses known-good-values (KGVs) of the hardware components along with keys and certificates rooted to Cisco, which are used to verify components of the hardware during the BIOS boot.
Chip Guard and Attestation are security features implemented in TAm to enable trust in hardware.
-
Chip Guard detects tampering attempts and responds by initiating actions such as disabling access to the device, erasing sensitive information stored in the device, or triggering a security alarm.
-
Attestation provides a mechanism for verifying the integrity and authenticity of the software and hardware components of a device.
A Cisco router with SUDI is authenticated and verified remotely for uniquely identifying that it’s an authentic Cisco device.
Note |
Some Cisco NCS 540 Series Routers have the older generation of chips with lesser capabilities compared to the latest TAm chips present on the newer generation of hardware. |
Chip Guard for Hardware Integrity
The chip guard feature helps detect if attackers have replaced a Cisco router’s ASIC or CPU with a counterfeit ASIC or CPU in the supply chain.
Need for Additional Hardware Integrity Check
The Cisco TAm chip and secure boot process anchored inside the hardware chip are enough to manage any threats around the boot process. Other threat factors include increased supply chain attacks, where attackers replace the ASIC or CPU on a router with malware-infested chips. Once the ASIC or CPU is replaced, the integrity of the hardware is compromised. The chip guard feature helps detect if there is a counterfeit ASIC or CPU on a router.
Stages in the Chip Guard Hardware Integrity Check
The table shows the various stages where the Chip Guard feature is triggered to ensure the integrity of the hardware:
|
Stage |
Process/Action |
Result |
|
|---|---|---|---|
|
Chip Manufacturing |
SHA 256 hashes of the electronic chip IDs of both the CPU and ASIC are programmed in the TAm chip |
The imprint DB inside the TAm chip contains the SHA 256 hashes, which cannot be modified during the router’s lifetime. |
|
|
Router Deployed in the Field and When BIOS is Triggered |
The chip guard feature recomputes the SHA 256 hashes of the electronic chip IDs of both the CPU and ASIC and creates an observed DB. |
The observed values are stored in the Observed DB inside the TAm chip. |
|
|
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 indicates that either the CPU or ASIC is modified, and the secure boot process halts. A message is displayed on the console about the chip guard validation failure.
|
Attestation
Attestation enables 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 the hardware and software of 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 can output the PCR quote and audit log, and it signs the quote using an attestation private key for that specific 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. Besides this, the verification ensures that the attestation is specific to a particular router by using attestation key pairs. These attestation key pairs are unique to each router. This ensures that attackers do not tamper with the router hardware, boot keys, boot configuration, and running software.
Proof of hardware integrity is recorded in the TAm as part of Chip Guard. This proof is made available through the following command:
Note |
The same data is also available through NETCONF for a remote attestation server: Cisco-IOS-XR-remote-attestation-act.yang. |
RP/0/RP0/CPU0:NCS-540-C-LNT#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=See the System Security Command Reference guide for more commands.
Feedback