MCU Security Options

From SEGGER Knowledge Base [STAGING]
Jump to navigation Jump to search

Most MCUs provide device-specific security features, such as read-out protection (RDP), code protection, lock bits, debug authentication, and lifecycle states. These features can restrict access through JTAG, SWD, and other debug or programming interfaces. They are relevant to protecting firmware, credentials, and other sensitive data in deployed products.

This article explains general protection, authorized service access, production provisioning, firmware update considerations, and the role of SEGGER tools. Debug protection is only one part of product security; it does not by itself provide secure boot, authenticated firmware updates, protection against vulnerabilities in running firmware, or resistance to all physical attacks.

Note:
Security configuration and recovery are device-specific. Check the silicon vendor's reference manual and the relevant device-family article before programming option bytes, fuses, or lifecycle states. Test the complete production and recovery sequences on the exact device revision and software version.

Protecting the debug interface

JTAG and SWD may let a debugger halt the CPU, inspect or change memory and registers, and program flash. An unrestricted interface can expose firmware and secrets or allow an attacker to change execution. MCUs may restrict readback, disable individual access ports, limit access to secure regions, or close the debug interface entirely. Protection may be controlled through option bytes, configuration words, fuses, or a product lifecycle state. Activation and reset requirements vary by device.

Common models include:

Read-out or code protection
Prevents some forms of external memory readback. The effect on CPU control, RAM, erase, and programming must be checked for the specific device and protection level.
Selective debug access
Restricts access to particular cores, access ports, memory regions, or security domains while retaining permitted functions. For example, a TrustZone-capable MCU may distinguish Secure and Non-Secure debug access.
Debug disable and lifecycle states
Close some or all debug access in a production state. Certain MCUs support authenticated reopening with limited permissions; others have no nondestructive recovery path.

Recoverable and irreversible protection

Some protections can be removed only by a device erase. The scope of that erase varies: firmware, secrets, configuration, or other nonvolatile data may be lost. Other transitions are irreversible for normal service, such as STM32 RDP Level 2. A vendor-specific authenticated debug mechanism may instead allow some access without a mass erase. Do not infer the recovery behavior from the name of a protection level alone.

Choose the production state based on the device threat model, update and repair needs, data-retention requirements, and vendor documentation. An erase-recoverable state can permit hardware reuse while protecting existing contents from ordinary debug readout. Where preserving data during failure analysis is required, evaluate the MCU's authorized debug facilities before committing to a protection state.

Production locking sequence

A representative sequence is:

  1. Select and validate the security policy for the exact MCU, including the permitted service and recovery paths.
  2. Program the bootloader, application, configuration, and other required images.
  3. Provision device-specific identity, credentials, certificates, or calibration data using a controlled process.
  4. Verify the programmed images and run tests that require unrestricted access.
  5. Apply the required debug restrictions or lifecycle transition at the appropriate point in the device-specific flow.
  6. Perform the reset or power cycle required to activate the new state, then check the resulting state using a permitted method. Verify that unauthenticated debug access is rejected where required.
  7. Record the device identity, firmware version, security state, operation result, and any exceptions in the production traceability system.

Locking should be the last step that needs unrestricted debug access, but the exact order of key provisioning, bootloader activation, verification, and locking depends on the MCU. Handle partial failures and interrupted jobs explicitly; do not ship a unit whose intended locked state has not been confirmed. If firmware performs first-boot locking, ensure that the first boot completes and verify the resulting state before release.

Authorized debug access and recovery

A product may need service access for repair or failure analysis. Decide at design time whether service should preserve firmware and data, allow only limited debug, or erase the device before reuse. The supported mechanism is determined by the MCU and its lifecycle configuration.

Authenticated debug
A device may verify a password, certificate, signed challenge response, or vendor-specific debug token. An authorized system obtains the device's challenge or identity, approves the request, and supplies the required response through a supported tool. The MCU determines the permitted access, duration, and whether a reset, relock, or erase is needed. A successful authentication does not universally imply full debug access or preservation of secrets.
Erase-based recovery
On supported devices, an unlock or regression operation can erase protected contents before restoring programming access. The erase scope and resulting security state are device-specific. Obtain authorization before attempting a connect or unlock operation that could erase a field unit.
Irreversible state
An irreversible protection level has no normal debug recovery path. Plan diagnostics and product updates through other supported interfaces before enabling it.

A service procedure should identify the device, check operator authorization, obtain any device-specific token without exposing private signing material, record the operation, carry out the supported access or erase sequence, and check the final state. Keep credentials out of command lines, logs, project files, and operator-visible storage where possible. Revoke or rotate service credentials according to the product's security design.

J-Link software supports protection detection and unlocking for selected device families. On some targets, a connection attempt may initiate an unlock that erases data. Review the behavior of the selected device, tool, and script before connecting to a production device. See the device-family documentation for supported operations.

Provisioning and firmware updates

Provisioning may program firmware, serial numbers, calibration values, device identities, certificates, public keys or hashes, and secret credentials. Define the flow with the MCU vendor's secure boot and lifecycle documentation. When a private key can be generated and retained inside secure hardware, prefer that design to transporting it through a programming station. If a secret must be injected, control its generation, transport, use, logging, and retention; verify the programmed state through a safe method before locking.

Sign release images in a controlled environment and provision the trust anchor required by the boot chain. Programming a signed image with J-Flash, DevPro, or custom J-Link SDK software does not itself verify the image at boot: the MCU or product bootloader must enforce signature verification. Encryption, where needed, has a separate confidentiality role.

For field updates, keep debug protection active during normal operation and have the product's update agent or secure bootloader authenticate the package before installation. Design for interrupted updates, version policy or rollback protection, and recovery. A J-Link-based repair flow for a field unit requires the relevant authorized debug or erase mechanism; it is not a replacement for a product's normal update protocol.

Using SEGGER tools

The host software performs the sequence supported by the target MCU; Security features vary by device series.

For device-specific information, consult the relevant article in Device families.

For Device Provisioner operations, consult the supported devices and features table and the linked feature articles.

Device Provisioner (DevPro)
A command-line tool included with J-Link and Flasher software. Its device-specific operations can cover debug authentication, option-byte programming, lifecycle management, regression, and other provisioning tasks where scripts are available. Select the exact operation and script from the supported devices and features table and the linked feature article.
J-Flash
Programs and verifies images. Device-specific Exit Steps can set security bits after successful production programming and, when enabled, verification. Exit Steps run for the Production Programming operation; Some algorithms also offer a separate Secure chip production step where supported.
J-Link Commander
Runs command files for device-specific reads, writes, programming, and unlock operations. Use documented sequences and check the process result and the device state. Raw option-byte writes require the correct address, width, prerequisite unlock, and reload sequence; avoid copying generic register-write examples to a different MCU.
J-Link SDK
Integrates J-Link programming and target access into customer production or service software. Authorization, key handling, approval, station identity, and audit records are responsibilities of that surrounding system unless separately supplied by another component.
J-Link script files
Customize connection and device-specific operations where needed.

Device-specific examples

For the current set of DevPro operations, consult Device Provisioner: Supported Devices and Features. Examples of related KB articles include:

Related SEGGER documentation

Retrieved from "https://kb.segger.com.staging.segger-sys.de/index.php?title=MCU_Security_Options&oldid=32302"