Chapter 1. Trustworthy Systems

- Trustworthy Systems

- Need for trustworthy systems

- Main components of trustworthy systems

- Cisco Secure Unique Device Identifier (SUDI)

- Trust Anchor Module (TAm)

Trustworthy Systems

Cisco trustworthy technologies offer product assurance and foundational security capabilities, thereby enhancing the security and resilience of Cisco solutions. To safeguard against device counterfeiting and malicious attacks on hardware and software, Cisco verifies the authenticity and integrity of its solutions using digitally signed software images, hardware-anchored secure boot, Secure Unique Device Identifier (SUDI), and various other trustworthy technologies. Beyond other capabilities, trustworthy technologies conduct automated integrity checks on hardware and software, capable of shutting down the boot process if a compromise is found. The Cisco Trust Anchor module offers a Secure Unique Device Identifier, highly secure storage, a random bit generator, and robust secure key management.

These additional layers of security offer protection against counterfeiting and software modification, facilitate secure and encrypted communications, and confirm that Cisco network devices are functioning as intended.

In trustworthy systems, trust originates at the lowest hardware levels and extends through the boot process, into the operating system (OS) kernel, and ultimately into the OS's runtime

Need for trustworthy systems

Complex computing and communications networks are essential for the uninterrupted operation of global service providers, enterprises, and government networks. The integrity of data and IT infrastructure is fundamental to ensuring network security and user trust. As personal data becomes accessible anywhere, anytime, users anticipate consistent access and security across all networks. With adversaries becoming more aggressive, the threat landscape itself is undergoing a transformation. It becomes even more crucial to protect networks from attacks by malicious actors and from counterfeit or tampered products.

Main components of trustworthy systems

The main components of implementing a trustworthy system are:

- Enabling trust in hardware with Hardware root-of-trust and secure JTAG

- Enabling trust in software with secure boot and secure iPXE

- Enabling and maintaining trust at steady state with Security-Enhanced Linux (SELinux), Secure install, and SSD Encryption

Cisco Secure Unique Device Identifier (SUDI)

Cisco's Secure Unique Device Identifier (SUDI) is an X.509 certificate, with its private key securely stored in the Trust Anchor Module during manufacturing, providing a tamperproof device ID. It plays a vital role in verifying the device's initial identity during onboarding and, more significantly, in confirming hardware authenticity and protecting against counterfeiting.

To uniquely identify a device, the SUDI combines the product ID and device serial number. As an IEEE 802.1AR compliant X.509v3 certificate (which can be RSA or ECC), it effectively prevents the cloning or spoofing of identity information, significantly aiding in the avoidance of counterfeit switches in the supply chain.

Trust Anchor Module (TAm)

The Cisco Trust Anchor module (TAm), a tamper-resistant chip embedded in Cisco 9000 Series Smart Switches , contains nonvolatile secure storage and acts as the foundation of the trust chain. Crucially, the manufacturer's public key is securely stored within the TAm chip of every Cisco 9000 Series Smart Switches .

Cisco 9000 Series Smart Switches incorporate ACT and ACT2 hardware chips to implement Anti-Counterfeit Technology (ACT) within the equipment.

The TAm includes the following things:

Identity

During the manufacturing process, a product’s ACT2 chip is loaded with the Cisco Secure Unique Device Identity (SUDI) in the form of an X.509v3 ECDSA or RSA certificate (or both), along with its corresponding keypairs and certificate chains. This SUDI serves as the foundation for Cisco’s hardware anti-counterfeit check and is also utilized for establishing the initial network identity.

Entropy

The ACT2 features a NIST SP 800-90B compliant entropy source, making it ideal for seeding host-based pseudo-random number generators.

Key Management

The ACT2 is capable of generating symmetric keys, as well as ECC and RSA asymmetric keypairs. Crucially, the symmetric keys and the private portions of these keypairs are never released from the chip. Access to these protected keys is facilitated solely through cryptographic APIs, and certificates can be enrolled for the keypairs generated by the ACT2.

Secure Storage

The ACT2 offers approximately 50 KB of host data storage, secured against physical tampering. This makes it an ideal repository for sensitive information like licenses and confidential data such such as credentials. Crucially, important switch keys and passwords are also safeguarded within this secure storage.

The TAm and SUDI in Cisco 9000 Series Smart Switches function similarly to a mobile device's IMEI (International Mobile Equipment Identity) number. Both serve as unique hardware identifiers while also providing additional functionalities.

The TAm features secure nonvolatile storage for cryptographic keys, which applications can access via TAm libraries. During switch bootup, the SUDI and boot measurements stored here are accessed to verify the switch's legitimacy and ensure the booting process executes as expected, thereby detecting any tampering.

Secure Boot

To ensure the authenticity and integrity of code executing on Cisco 9000 Series Smart Switches , Cisco employs Secure Boot. Its hardware-anchored secure boot safeguards the micro loader—the very first piece of code that boots—within tamper-resistant hardware. This creates a root of trust, effectively preventing Cisco network devices from running tainted network software.

All images released by Cisco are digitally signed using the manufacturer's private key. This process occurs in an isolated, secure, and audited environment. The key pair itself is generated using RSA encryption with a 2048-bit modulus.

The device, after booting, authenticates with the TAm through SUDI to ascertain that its hardware is indeed genuine Cisco, rather than a counterfeit or compromised unit.

The public key, embedded directly into the hardware, is accessible via TAm libraries. Cisco IOS XE images are signed using private keys that are never removed from the build DevOps release environment. During the boot process, these keys are compared, confirming that both the hardware and software have been signed by Cisco.

The secure chain begins with the TAm, which first verifies the integrity of the microloader before it's loaded onto the CPU. In a similar fashion, the microloader then verifies the BIOS/bootloader by calling the TAm's API to ensure its image is legitimate before loading it. This same verification process is applied when loading the Cisco IOS XE image.

After the CPU loads the image, the operating system utilizes the TAm API to verify software modules like KLM, RPM, and ASIC SDK prior to their activation.

Chip Guard (Chip Protection)

Cisco 9000 Series Smart Switches incorporate a chip protection feature that guarantees hardware integrity. This protection mechanism records each device's signature during manufacturing and then compares it during every device bootup, thereby ensuring that the switch's peripherals are not counterfeit.

Manufacturing Time Database

The manufacturing time database is the original copy of the unique IDs of Cisco ASICs, CPUs, SoCs, and other devices with their device types specific to a board. In most cases, the unique ID is a device serial number or other appropriate value of that device. The manufacturing database is a Known Good Values (KGV) database specific to a board. It is programmed onto the TAm device as part of the manufacturing process.

Collected Database

The collected database is collected by the firmware whenever the board is booted and extended to the TAm device. Measurements are collected either through firmware or through system drivers.

The BIOS boot process integrates the TAm library to populate the collection database. The BIOS detects various hardware components as part of initialization and uses the TAm library APIs to record the device type and unique IDs if the detected devices are part of the manufacturing time database. After all the device types and unique IDs are written to the collected database, the platform operating system invokes the TAm library API to validate the collected database against the manufacturing time database. If there is a mismatch, the platform holds the boot process.

Random Number Generation and Entropy Source

Strong random number generation (RNG) is at the core of encryption, while weak RNG can undermine the entire encryption system. Random number generators play a key role in creating cryptographic keys, establishing highly secure communications between users and websites, and in resetting passwords for email accounts. Without assured randomness, an attacker can predict what the system will generate and undermine the algorithm. Cisco 9000 Series Smart Switches uses the RNG from Linux. The RNG is seeded with a random value, typically obtained from a hardware random number generator (HRNG), which makes it impossible to guess. Hardware also contains a Trust Anchor module that is compliant with NIST specifications and capable of providing much more effective RNG that extracts entropy from a true random source within the Trust Anchor.

Multistage BIOS

The BIOS is split into multiple, smaller pieces so that they can be loaded, validated, and executed entirely in the RAM to protect the BIOS from external modification (such as a Time-of-Check to Time-of-Use attack [1]). The BIOS is composed of the following things:

- Pre-EFI Initialization (PEI)

- Firmware Dependency Module (FDM)

- Driver Execution environment (DXE)

Having a multistage BIOS in Cisco 9000 Series Smart Switches makes it very hard to bypass the Cisco BIOS. Any intervention with the BIOS will stop the bootloader from loading the OS image

Runtime Defenses (RTD)

Runtime defenses target injection attacks of malicious code into running software. Cisco 9000 Series Smart Switches runtime defenses include Address Space Layout Randomization (ASLR), Built-in Object Size Checking (BOSC), and X-space Runtime defenses. These defenses make it harder or impossible for attackers to exploit vulnerabilities in running software.

Address Space Layout Randomization (ASLR)

Address Space Layout Randomization (ASLR) is an important security hardening functionality that randomizes the locations of sections of all processes and the kernel for Cisco 9000 Series Smart Switches to make it more difficult for an attacker to exploit existing vulnerabilities. ASLR is a companion defense along with executable space protection, which prevents inadvertent execution of code from unauthorized areas and prohibits writing of code over executable areas.

ASLR functionality for processes can be categorized into Cisco binaries and 3rd party binaries, both of which need to support ASLR. For ASLR support, Cisco and 3rd party binaries and shared libraries need to be built with the correct flags. Cisco binaries including 3rd party shared objects must ensure the library is randomized so as not to compromise the randomization of the Cisco binary itself. 3rd party binaries and shared libraries might require vendor support to randomize them.

ASLR functionality for the Linux kernel brings support for address space randomization to running Linux kernel images by randomizing where the kernel code is placed at boot time. Kernel ASLR support is present in Cisco 9000 Series Smart Switches , making it hard for the hackers to perform malicious code injections.

Executable Space Protection (XSpace)

Executable space protection (X-space) is one of the most important security protections in Cisco 9000 Series Smart Switches . This feature ensures that executable space protection is enabled for Cisco devices, which prevents the execution of code from unauthorized areas and prohibits writing code over executable areas.

X-space makes Cisco devices more robust at preventing hackers from penetrating into the switches.

Object Size Checking (OSC)

Buffer overflow is probably the best-known form of software security vulnerability. A buffer overflow condition exists when a program attempts to put more data in a buffer than the buffer can hold, or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code. switches have full protection to determine buffer overflows in C or C++ code by having object size checks before a write call.

SafeC Libraries

Cisco IOS XE software uses efficient library functions that promote safer, more secure C or C++ language programming and are based on the ISO/IEC 9989:2011 (C11) specification. Several standard C library functions are susceptible to vulnerabilities that can serve as launch points for more sophisticated attacks.

While providing "safe" replacements for standard functions in a consistent naming schema, SafeC aims to mitigate security exploits due to buffer overflows, provides bound checks that may not be present in the native library, and prevents string termination and truncation errors. This SafeC safeguards Cisco 9000 Series Smart Switches hardware from buffer overflow attacks.

Cisco Signed Kernel Modules

Signed Kernel Modules ensure that any kernel modules loaded into the system are authentic and unmodified. This prevents unapproved and untrusted executable code from being loaded into the kernel by conventional means.

If the modules are not signed by Cisco, then they cannot be used with the Cisco IOS XE. This feature stops unauthorized software from running on Cisco devices. All these hardening features make the Cisco IOS XE and its peripheral components difficult to hack.

Secure JTAG (sJTAG)

JTAG was also adopted to program FPGAs and provide a CPU debug access port. A laptop and a JTAG debugger are often all that is required to provide access to an embedded CPU allowing for retrieval of firmware images, dumping memory, and monitoring software execution. A small size interface coupled with a sophisticated toolset gives attackers a portable yet powerful means to exploit a system.

By having a secure JTAG on Cisco 9000 Series Smart Switches , we can mitigate intellectual property (IP) theft and avoid the stealing of passwords or keys from the memory.

Secure Erase

The secure erase feature erases all customer information within Cisco 9000 Series Smart Switches . Secure erase is an operation that removes all the identifiable customer information in Cisco IOS XE devices for purposes of product removal due to Return Material Authorization (RMA), upgrade or replacement, or system end-of-life.

- RMA for a device: If you must return a device to Cisco for RMA, remove all customer-specific data before obtaining an RMA certificate for the device.

- Recovering a compromised device: If the key material or credentials that are stored on a device are compromised, reset the device to the factory configuration, and then reconfigure the device.

[1] A Time-of-Check to Time-of-Use (TOC/TOU) attack is a type of race condition vulnerability that occurs when a program checks a condition and then performs an action based on the result of that check. However, if another program modifies the condition between the time of the check and the time of the use, the action will be performed based on the modified condition, which could lead to unintended consequences.

Chapter 2. BIOS Protection

- BIOS protection

- Primary ROMMON and golden ROMMON

- Upgrade on standalone, high availability, and SVL devices

- Capsule upgrade

BIOS protection

The BIOS protection feature provides write-protection for the golden ROMMON image and ensures that any upgrades to this image are performed securely.

Without the BIOS protection feature, the golden ROMMON image is vulnerable to corruption by malicious code during software upgrades.

Primary ROMMON and golden ROMMON

ROMMON images are stored on the SPI flash device as both primary ROMMON and golden ROMMON

The primary ROMMON is used to boot the device each time it is powered on or restarted. If the primary ROMMON becomes corrupted, the device automatically uses the golden ROMMON to boot the IOS XE software image.

When the device boots from the primary ROMMON, the golden ROMMON remains locked.

With the BIOS protection feature enabled, the golden ROMMON is write-protected and cannot be upgraded using the standard flash utility upgrade mechanism. Access policies for the golden ROMMON are enforced by the FPGA firmware, which blocks unauthorized operations such as write and erase commands on the golden ROMMON SPI flash device.

Note

Golden ROMMON upgrade is not enabled without secure-boot FPGA upgrade.

Upgrade on standalone, high availability, and SVL devices

The upgrade process varies between standalone, high availability, and SVL devices. The following table explains how upgrade process works.

Upgrade on standalone, high availability, and SVL devices

Device configuration

Upgrade process

Standalone device

Upgrading in install mode automatically upgrades the primary ROMMON when the device boots. The golden ROMMON, however, can only be upgraded using the capsule upgrade process.

High availability and StackWise Virtual devices

It is recommended to perform an In-Service Software Upgrade (ISSU) for devices configured in a high availability setup, as FPGA upgrades are included as part of the ISSU process.

If you are upgrading in install mode with reload, avoid reloading both supervisors simultaneously. Instead, while the standby supervisor is in the ROMMON state, boot the active supervisor first. Once the ROMMON upgrade is completed on each supervisor, the FPGA and software image are also upgraded. Afterward, boot the standby supervisor and allow it to complete its upgrade and reach the standby hot state

Capsule upgrade

The primary ROMMON, primary FPGA, and golden FPGA (secure-boot FPGA) are automatically upgraded when the device boots. In contrast, the golden ROMMON can only be upgraded using the capsule upgrade process, ensuring an additional layer of security for critical boot components.

In a capsule upgrade, a secure update capsule is created and digitally signed, and is used by the primary ROMMON to upgrade the golden ROMMON after authentication. This process requires a secure flash certificate, which is generated using the product key and included in the primary ROMMON image to verify the authenticity of the update capsule. The capsule itself is created using the secure flash certificate along with a secure boot 16 MB flash image, and is then signed to ensure the integrity and authenticity of the upgrade.

When the device boots, the primary ROMMON initiates the capsule upgrade process for the golden ROMMON. To manually perform a capsule upgrade for the golden ROMMON, use the upgrade rom-monitor capsule golden command on a switch or the upgrade rom-monitor capsule golden switch command on a switch switch in privileged EXEC mode.

- How Capsule Upgrade works

How Capsule Upgrade works

Workflow

The following details the process that occurs in a capsule upgrade:

1. The device checks if secure-boot FPGA upgrade is enabled. If not, the process exits.

2. The device checks if bootloader protection is enabled. If not, a one-time upgrade of primary ROMMON, golden ROMMON, and primary FPGA is initiated.

3. If bootloader protection is already active, IOS copies the secure update capsule to bootflash and the device reboots.

4. When the device reboots, secure update capsule is picked for performing the upgrade.

Chapter 3. Boot Integrity Visibility

- Boot Integrity Visibility

- How boot integrity visibility works

- Image signing

- Verify software image and hardware

Boot Integrity Visibility

Boot integrity visibility acts as a hardware trust anchor by validating the ROMMON software to ensure its integrity.

Boot integrity visibility enables Cisco platforms to make both platform identity and software integrity information visible and actionable. Platform identity refers to the unique identity assigned during manufacturing, ensuring each device can be reliably identified. Software integrity involves capturing boot integrity measurements, which help determine whether the platform has started up using trusted code.

Catalyst 9000 Series Switches support boot integrity visibility feature.

How boot integrity visibility works

Summary

When a Cisco IOS XE image is copied onto a Cisco 9000 Series Smart Switches , the ROMMON Boot ROM verifies the image using Cisco release keys. These release keys are public keys that correspond to the private release key securely stored on the Cisco servers. The public release key is embedded within the ROMMON, enabling the switch to validate the authenticity and integrity of the Cisco IOS XE image before booting.

Workflow

The ROMMON follows these steps when it verifies a signed Cisco IOS XE image during the bootup:

1. Loads the Cisco IOS XE image into the CPU memory.

2. Examines the Cisco IOS XE package header.

3. Runs a non-secure integrity check on the image to ensure that there is no unintentional file corruption from the disk or TFTP. This is performed using a non-secure SHA-1 hash.

Note

This step is a non-secure check of the image which is intended to confirm the image against inadvertent corruption due to disk errors, file transfer errors, or copying errors. This is not part of the image code signing. This check is not intended to detect deliberate image tampering.

4. Copies the Cisco's RSA 2048-bit public release key from the ROMMON storage and validates that the Cisco's RSA 2048-bit public release key is not tampered.

5. Extracts the Code Signing signature (SHA-512 hash) from the package header and verifies it using Cisco's RSA 2048-bit public release key.

6. Performs the Code Signing validation by calculating the SHA-512 hash of the Cisco IOS XE package and compares it with the Code Signing signature. The Signed package is now validated.

7. Examines the Cisco IOS XE package header to validate the platform type and CPU architecture for compatibility.

8. Extracts the Cisco IOS XE software from the Cisco IOS XE package and boots it.

Note

Image Code Signing validation occurs in step 4, 5, and 6. This is a secure code signing check of the image using an SHA-512 hash that is encrypted with a 2048-bit RSA key. This check is intended to detect deliberate image tampering.

If the software is not generated by a Cisco build system, the signature verification fails. The device ROMMON rejects the image and stops booting.

If the signature verification is successfully, the device boots the image to the Cisco IOS XE runtime environment.

Image signing

The Cisco build servers generate the Cisco IOS XE images. The Cisco IOS XE image is digitally signed during the build time. An SHA-512 hash is generated over the entire binary image file, and then the hash is encrypted with a Cisco RSA 2048-bit private key.

Verify software image and hardware

This section describes how to retrieve the checksum record that was created during a switch bootup. Enter the following commands in privileged EXEC mode.

Command to retrieve the checksum records

Command

Description

show platform sudi certificate [sign [nonce nonce]]

Displays checksum record for the specific SUDI.

- (Optional) sign: Show signature

- (Optional) nonce: Enter a nonce value

show platform integrity [sign [nonce nonce]]

Displays checksum record for boot stages.

- (Optional) sign: Show signature

- (Optional) nonce: Enter a nonce value

Chapter 4. Consent Token

- Consent Token

- How consent token authorization works

- Consent token authorization process for system shell access

Consent Token

Consent Token is a security feature that authenticates the network administrator of an organization to access system shell with mutual consent from the network administrator and Cisco Technical Assistance Centre (Cisco TAC).

In some debugging scenarios, the Cisco TAC engineer may have to collect certain debug information or perform live debug on a production system. In such cases, the Cisco TAC engineer will ask you (the network administrator) to access system shell on your device. Consent Token is a lock, unlock and re-lock mechanism that provides you with privileged, restricted, and secure access to the system shell.

How consent token authorization works

Summary

When you request access to system shell, you need to be authorized. You must first run the command to generate a challenge using the Consent Token feature on your device. The device generates a unique challenge as output. You must then copy this challenge string and send it to a Cisco Authorized Personnel through e-mail or Instant Message.

The Cisco Authorized Personnel processes the unique challenge string and generates a response that is unique. The Cisco Authorized Personnel copies this response string and sends it to you through e-mail or Instant Message.

You must then input this response string into your device. If the challenge-response pair match, you are authorized to access system shell. If not, an error is displayed and you are required to repeat the authentication process.

Once you gain access to system shell, collect the debug information required by the Cisco TAC engineer. After you are done accessing system shell, terminate the session and continue the debugging process.

Workflow

Consent Token

1. Generate a challenge requesting for access to system shell for the specified time period.

2. Send the challenge string to a Cisco Authorized Personnel.

3. Input the response string onto your device.

4. Terminate the session.

Consent token authorization process for system shell access

This procedure details the Consent Token authorization process to access system shell.

Procedure

Step 1

Send a request for a challenge using the request consent-token generate-challenge shell-access time-validity-slot command.

Example:

Device# request consent-token generate-challenge shell-access auth-timeout 900
zSSdrAAAAQEBAAQAAAABAgAEAAAAAAMACH86csUhmDl0BAAQ0Fvd7CxqRYUeoD7B4AwW7QUABAAAAG8GAAhDVEFfREVNTwcAGENUQV9ERU1PX0NUQV9TSUdOSU5HX0tFWQgAC0M5ODAwLUNMLUs5CQALOVpQUEVESE5KRkI=
Device#
*Jan 18 02:47:06.733: %CTOKEN-6-AUTH_UPDATE: Consent Token Update (challenge generation attempt: Shell access 0).

time-validity-slot : The duration in minutes for which you are requesting access to system shell.

In this example, the time period is 900 minutes after which the session expires.

The device generates a unique challenge as output. This challenge is a base-64 format string.

Step 2

Send the challenge string generated by the device to a Cisco Authorized Personnel through e-mail or Instant Message.

The Cisco Authorized Personnel processes the unique challenge string and generates a response. The response is also a base-64 string that is unique. The Cisco Authorized Personnel copies this response string and sends it to you through e-mail or Instant Message.

Step 3

Input the response string sent to you by the Cisco Authorized Personnel using the request consent-token accept-response shell-access response-string command.

Example:

Device# request consent-token accept-response shell-access lR1y2AAUKFcAAAABAAABYlVDZ2d6MnkxL3JxTTJSSC9FZE5aWnRSa1FteS9POWZqRUNlTk1LL3VoUWxTc0FsOHl5OW5vckQ4YWVOelpZZGYNCkNpWHY0b1B4Q000UGs1M2ZEMUpoazBCUkYyM3FML1A2ckVjM3paR05wdHcvck95UVduYUVuTnA5bnhIZ09CNE0NCjBmVjh4b3I4TzE3aHNMaU1JeDQ3YWtkdE9Xb0JhTmlzMVRweFBVZE93QUxvZDVEbmo4UEtiR01VVUM5b3lZWXQNCjFIRnJPbXczcmpsZTJHUnIxOWJUNkZLTWlpZ0ZmbENVRWo4K2xoaXgxS0ZtdDVPcDBYczVPSU43L0dSK1pGTnoNCmYxTUtjaW1OWDhWTTNLQ0ZWNURHU3pIenF1UFBxZVNDU0xLNkhXUTFROTlFMXJVakdlZ1NqTWxnNFlySkJYL0wNCnpaTDVVRnVFdWpRWDdDUThIdkVPM1E9PQ==
% Consent token authorization success
*Jan 18 02:51:37.807: %CTOKEN-6-AUTH_UPDATE: Consent Token Update (authentication success: Shell access 0).

Device# request platform software system shell
Activity within this shell can jeopardize the functioning of the system.
Are you sure you want to continue? [y/n] y
Device#
*Jan 18 02:56:59.714: %CTOKEN-6-AUTH_UPDATE: Consent Token Update (authorization for Shell access 0 will expire in 10 min).

If the challenge-response pair match, you are authorized to access system shell. If the challenge-response pair do not match, an error is displayed and you are required to repeat steps 1 to 3.

After you are authorized, you can access system shell for the requested time-slot.

The device sends a message when there is ten minutes remaining of the authorization session.

Step 4

When you finish accessing system shell, you can end the session using the request consent-token terminate-auth command. You can also force terminate the session prior to the authorization timeout using this command. The session also gets terminated automatically when the requested time slot expires.

Example:

Device# request consent-token terminate-auth
% Consent token authorization termination success

Device#
*Jan 18 23:33:02.937: %CTOKEN-6-AUTH_UPDATE: Consent Token Update (terminate authentication: Shell access 0).
Device#

Chapter 5. Factory Reset

- Factory Reset

- Secure Data Wipe

- Guidelines to perform factory reset

- Perform a Factory Reset

Factory Reset

A factory reset deletes all customer-specific data stored on a device and restores the device to its original configuration as it was at the time of shipping. This process erases configurations, log files, boot variables, core files, and credentials, including Federal Information Processing Standard (FIPS)-related keys. The data erasure performed during a factory reset aligns with the clear method defined in NIST Special Publication 800-88 Revision 1.

- When do you need to do factory reset

- What happens during a factory reset

When do you need to do factory reset

You need to perform factory reset in the following scenarios

- Return Material Authorization (RMA) for a device

If you need to return a device to Cisco for RMA, remove all the customer-specific data before obtaining an RMA certificate for the device.

- Recovering a compromised device

If the key material or credentials that are stored on a device are compromised, reset the device to the factory configuration, and then reconfigure the device.

What happens during a factory reset

1. During a factory reset, the device reloads and enters ROMMON mode.

After the factory reset, the device removes all its environment variables, including the MAC_ADDRESS and the SERIAL_NUMBER variables, which are required to locate and load the software.

2. Perform a reset in ROMmon mode to automatically set the environment variables.

The BAUD rate environment variable returns to its default value after a factory reset. Make sure that the BAUD rate and the console speed are the same at all times. Otherwise, the console becomes unresponsive.

3. After the system reset in ROMmon mode is complete, add the Cisco IOS XE either through an USB or TFTP.

The following table provides details about the data that is erased and retained during the factory reset process:

Data erased and retained during a factory reset

Data erased

Data retained

All Cisco IOS XE images, including the current boot image

Data from remote field-replaceable units (FRUs)

Crash information and logs

Value of the configuration register.

User data, startup and running configuration, and contents of removable storage devices, such as Serial Advanced Technology Attachment (SATA), Solid State Drive (SSD), or USB

—

Credentials such as FIPS-related keys

Credentials such as Secure Unique Device Identifier (SUDI) certificates, and public key infrastructure (PKI) keys.

Onboard Failure Logging (OBFL) logs

—

ROMmon variables added by a user.

—

Licenses

—

Secure Data Wipe

The device storage is utilized to maintain software images, device configurations, software logs, and operational history. Customer-specific data may be present in any of these areas, and this information can include details about the network architecture and design implemented by customers.

How to do secure data wipe

To perform secure data wipe, use the all secure option in the factory-reset command. This performs data sanitization and securely resets the device. After data sanitization, the device reloads and boots with the software image present in flash.

Secure data wipe standards

Secure data wipe feature implements guidelines for media sanitization as described in NIST SP 800-88 Rev. 1. NIST 800-88 is a standard published by the National Institute of Standards and Technology (NIST) that provides guidelines for media sanitization.

The PURGE standard within NIST 800-88 specifies methods to render data on storage media unrecoverable using laboratory techniques. When a device is sanitized using NIST 800-88 PURGE method, data cannot be recovered through simple non-invasive data recovery techniques or advanced laboratory techniques.

Guidelines to perform factory reset

- Ensure that all the software images, including the current image, configurations, and personal data are backed up before you begin the factory reset process.

- Ensure that there is uninterrupted power supply when the factory reset process is in progress.

- Ensure that In-Service Software Upgrade (ISSU) are not in progress before you begin the factory reset process.

- Software patches, if installed on the device, will not be restored after the factory reset process.

- If the factory-reset command is issued through a VTY session, the session is not restored after completion of the factory reset process.

- The config keyword of the factory-reset command is not supported when the switch is in stacking or Stackwise Virtual Link (SVL) mode.

- For modular chassis devices configured in high-availability mode, factory reset must be applied on each supervisor module.

Perform a Factory Reset

Perform this procedure for a factory reset.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password, if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

Configure one of these commands based on the switch configuration:

- Switch

factory-reset {all [secure] [3-pass] | config | boot-vars}

- Switch stack

factory-reset {all [secure 3-pass] | config | boot-vars | switch {switch-number | all {all [secure 3-pass] | config | boot-vars}}

Example:

Device(config)# factory-reset all
OR
Device(config)# factory-reset all secure

Resets the device to its configuration at the time of its shipping.

Note

No system configuration is required to use the factory reset command.

- all : Erases all the content from the NVRAM, all the Cisco IOS XE images, including the current boot image, boot variables, startup and running configuration data, and user data. We recommend that you use this option.

- all secure : Performs data sanitization and securely resets the device.

Note

- You can use the all secure option only on standalone devices.

This option implements guidelines for media sanitization as described in NIST SP 800-88 Rev. 1.

- The factory-reset all secure command initiates data sanitization. The booted image of the device is retained.

When data sanitization is completed, the device reloads, and the device image is retained in flash if it was booted with an image from the flash.

- secure 3-pass : Erases all the content from the device with 3-pass overwrite.

- Pass 1: Overwrites all addressable locations with binary zeroes.

- Pass 2: Overwrites all addressable locations with binary ones.

- Pass 3: Overwrites all addressable locations with a random bit pattern.

Note

This option takes approximately thrice the time taken to perform any other option.

- config : Resets the startup configurations.

- boot-vars : Resets the user-added boot variables.

- switch {switch-number | all} :

- switch-number : Specifies the switch number.

- all : Selects all the switches in the stack.

After the factory reset process is successfully completed, the device reboots and enters ROMmon mode.

Chapter 6. Secure Storage

- Secure Storage

- Enable secure storage

Secure Storage

The Secure Storage feature protects critical configuration information by encrypting it. This includes asymmetric key-pairs, pre-shared secrets, the type 6 password encryption key, and specific credentials. To ensure security, an instance-unique encryption key is stored within the hardware trust anchor, preventing unauthorized access or compromise.

Enable secure storage

Secure storage is disabled by default. Perform this task to enable secure storager.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password, if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

[no] service private-config-encryption

Example:

Device(config)# service private-config-encryption

Enables secure storage on the device.

Use the no form of this command to disable secure storage on the device

Note

When secure storage is disabled, all the user data is stored in plain text in the NVRAM.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

write memory

Example:

Device# write memory

Encrypts the private-config file and saves the file in an encrypted format.

Read Me First

Only supported features are documented. To confirm or clarify all the supported features for a platform, go to Cisco Feature Navigator.

Full Cisco Trademarks with Software License

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)