Show Contents

# 4. Secure the device

The final step in configuring secure boot for a device is burning the secure eFuse configuration.

CAUTION! The secure eFuse configuration can only be written once and is irreversible.

To secure the device:

## Program the SRK eFuse

The SRK fuses hold the hash of the SRK public keys. In open devices, they are never used. In closed devices, they are used to validate the public key contained in signed firmware images.

Before closing the device, you must store the hash of the public keys in the SRK OTP bits on the device. This will allow the ROM loader to validate the public key included in signed firmware images. When building signed U-Boot images, Yocto generates a file named SRK_efuses.bin, which can be used to program the SRK efuses from the U-Boot shell in a safe way following this procedure:

From the U-Boot prompt, load the SRK_efuses.bin file to memory using TFTP:

    # Get the SRK_efuses file and load it to $loadaddr
    => tftp $loadaddr SRK_efuses.bin
    Using FEC device
    TFTP from server 192.168.129.10; our IP address is 192.168.42.30
    Filename 'deploy/SRK_efuses.bin'.
    Load address: 0x12000000
    Loading: #
             15.6 KiB/s
    done
    Bytes transferred = 32 (20 hex)

Program the device using the trustfence prog_srk command:

    # Burn the SRK efuses using the file (placed in $loadaddr, size is deduced from tftp command)
    => trustfence prog_srk $loadaddr $filesize
    Warning: Programming fuses is an irreversible operation!
             This may brick your system.
             Use this command only if you are sure of what you are doing!
    Really perform this fuse programming? <y/N>

The filesize environment variable is automatically calculated from the previous tftp command to be equal to the size (in bytes) of the hex-format SRK_efuses.bin file.

See Revoke a key for steps to take if any of these keys are compromised.

To simplify key management, Digi recommends you program all devices with the same set of four keys.

## Close the device

To close a device, issue Digi's U-Boot trustfence close command as follows and then reset the target:

    => trustfence close
    => reset

After that, the device will only boot properly signed images.

This step is irreversible and could brick your device.

Before closing the device:

- Verify you have programmed a signed, not encrypted, U-Boot image.
- Verify there are no HAB events.
- Verify the SRK eFuses are burned. The SRK OTP bits are not verified on open devices. For a closed device to boot, all the SRK OTP bits must be burned. An open device booting with no HAB events will stop booting after being closed if the SRK OTP bits are invalid, not burned, or only partially burned.

The U-Boot environment encryption feature is enabled by default, so U-Boot will import the MAC addresses (and any other write-once environment variables) from the previous (not encrypted) environment, and will reset any other variable to the default values. After that it will overwrite the environment with encrypted data.

To ensure that both copies of the environment get encrypted, save the environment twice right after flashing a U-Boot with environment encryption support, as follows:

    => saveenv

    Erasing NAND...
    Erasing at 0x320000 -- 100% complete.
    Writing to NAND... OK
    => saveenv

    Erasing redundant NAND...
    Erasing at 0x320000 -- 100% complete.
    Writing to redundant NAND... OK

After you have closed the device, consider the following points regarding how firmware authentication can potentially be skipped:

- JTAG could be used to boot the processor and avoid the secure boot. See Secure JTAG.
- U-Boot will drop to a console after an unsuccessful firmware authentication for debugging purposes. That console can still be used to boot, so it should be disabled in production firmware. See Secure console modes.
- Direct External Memory Boot could bypass firmware authentication. Digi recommends burning the DIR_BT_DIS fuse on closed devices to prevent this.

© 2018 Digi International Inc. All rights reserved.
4. Secure the device updated on 22 January 2018 02:43:38 PM