This feature is currently not supported on the ConnectCore 8X.

Most embedded devices provide a JTAG interface for debugging purposes. However, if left unprotected, this interface can become an important attack vector on the system. The i.MX6 series System JTAG Controller (SJC) allows you to regulate JTAG access with three security modes using OTP (One Time Programmable) eFuses:

  • Disable:

    • Disabled JTAG: This mode provides maximum security. All security-sensitive JTAG features are permanently blocked, preventing any debug. This mode is not recommended as boundary scan is currently used by Digi on its manufacturing process and could affect the RMA procedure.

    • Disabled debugging: This mode disables debugging but leaves the boundary scan functionality enabled. This is the recommended mode for maximum security.

  • Enabled: This mode provides low security. This is the default mode of operation.

  • Secure: This mode provides high security. JTAG use is regulated by a 56-bit secret key-based challenge/response authentication mechanism. 

image

The response key must be programmed in the target and configured in the debug tool.

Secure JTAG key management

Key management is an important consideration when configuring the secure JTAG mode. The response key can be:

  • A unique key for all devices. Compromising this key would make all deployed devices subject to attack.

  • A key per device.

    • The keys and device identification, such as the serial number or MAC address, must be kept in a secure database.

    • A secure algorithm can be used to generate a response key from the device identification such as the serial number or MAC address. In this case, compromising the algorithm would make all deployed devices vulnerable.

Key management implementation is customer-dependent.

Program JTAG security mode

JTAG functionality is enabled by default. Digi’s U-Boot provides the trustfence jtag command that allows you to permanently change the secure JTAG mode.

Programming eFuses is an irreversible operation and should only be done at the final stages of product manufacturing. OTP confguration can still be overwritten using the shadow registers unless the JTAG mode is locked.

To permanently program the JTAG configuration by burning the eFuses, execute the following command sequence:

=> trustfence jtag prog <mode>

In this sequence, mode can be one of the following strings:

  • disable-jtag, to block all JTAG features.

  • disable-debug, to disable JTAG debugging while allowing boundary scan.

  • secure, for secure JTAG mode. In this mode, the response key also needs to be programmed into the eFuses as follows:

    => trustfence jtag prog_key <high> <low>

    A quick way to generate a random response key on a Linux machine is:

    ~$ openssl rand -hex 7 | sed 's,^\([[:xdigit:]]\{6\}\)\([[:xdigit:]]\{8\}\),0x00\1 0x\2,g'

Lock JTAG mode

Once the desired JTAG interface configuration is programmed, you must lock the JTAG mode configuration so it cannot be overwritten by the OTP shadow registers.

To protect the JTAG mode configuration, use the following command:

=> trustfence jtag lock

To protect the response key from being read or overwritten, use the following command:

=> trustfence jtag lock_key

Configure secure JTAG with IDE

When configuring secure JTAG mode, you must set up your debugger tool to verify the response key sent by the target device and make debugging possible. This example uses the ARM DStream DS-5 Eclipse-based IDE debugger tool.

  1. Enter the Eclipse environment into the Run>Debug Configurations>DS-5 Debugger menu.

  2. Select the configuration created for your debug session.

    image

  3. Click DTSL Options. A new dialog appears.

  4. Select the SJC tab and enable the Secure JTAG support by clicking the checkbox.

    image

  5. Enter the response key into the SJC key field. This is the same key that has been set up on the target eFuses with the trustfence jtag prog_key command.

The debugger is now ready to connect to the target again. In the case of a response key mismatch, the debugger will not be able to connect to the target.