Burn Key
The espefuse.py burn_key
command burns keys to eFuse blocks:
Positional arguments:
block
- Name of key block.Keyfile
. It is a raw binary file. The length of binary key depends on the key purpose option. For theECDSA_KEY
purpose usePEM
file.Key purpose
. The purpose of this key.
It can be list of key blocks and keyfiles and key purposes (like BLOCK_KEY1 file1.bin USER BLOCK_KEY2 file2.bin USER etc.).
Optional arguments:
--no-write-protect
. Disable write-protecting of the key. The key remains writable. The keys use the RS coding scheme that does not support post-write data changes. Forced write can damage RS encoding bits. The write-protecting of keypurposes does not depend on the option, it will be set anyway.--no-read-protect
. Disable read-protecting of the key. The key remains readable software. The key with keypurpose [USER, RESERVED and .._DIGEST] will remain readable anyway, but for the rest keypurposes the read-protection will be defined by this option (Read-protect by default).--force-write-always
. Write the eFuse key even if it looks like it is already been written, or is write protected. Note that this option can’t disable write protection, or clear any bit which has already been set.--show-sensitive-info
. Show data to be burned (may expose sensitive data). Enabled if –debug is used. Use this option to see the byte order of the data being written.
ESP32-H2 supports eFuse key purposes. This means that each eFuse block has a special eFuse field that indicates which key is in the eFuse block. During the burn operation this eFuse key purpose is burned as well with write protection (the --no-write-protect
flag has no effect on this field). The ESP32-H2 chip supports the following key purposes:
USER.
RESERVED.
ECDSA_KEY. It can be ECDSA private keys based on NIST192p or NIST256p curve. The private key is extracted from the given file and written into a eFuse block with write and read protection enabled. This private key shall be used by ECDSA accelerator for the signing purpose.
XTS_AES_128_KEY. 256 bit flash encryption key.
HMAC_DOWN_ALL.
HMAC_DOWN_JTAG.
HMAC_DOWN_DIGITAL_SIGNATURE.
HMAC_UP.
SECURE_BOOT_DIGEST0. 1 secure boot key.
SECURE_BOOT_DIGEST1. 2 secure boot key.
SECURE_BOOT_DIGEST2. 3 secure boot key.
ESP32-H2 has the ECDSA accelerator for signature purposes and supports private keys based on the NIST192p or NIST256p curve. These two commands below can be used to generate such keys (PEM
file). The burn_key
command with the ECDSA_KEY
purpose takes the PEM
file and writes the private key into a eFuse block. The key is written to the block in reverse byte order.
For NIST192p, the private key is 192 bits long, so 8 padding bytes (“0x00”) are added.
> espsecure.py generate_signing_key -v 2 -s ecdsa192 ecdsa192.pem
ECDSA NIST192p private key in PEM format written to ecdsa192.pem
> espsecure.py generate_signing_key -v 2 -s ecdsa256 ecdsa256.pem
ECDSA NIST256p private key in PEM format written to ecdsa256.pem
All keys will be burned with write protection if --no-write-protect
is not used.
Only flash encryption key is read protected if --no-read-protect
is not used.
All keys, except flash encryption, will be burned in direct byte order. The encryption key is written in reverse byte order for compatibility with encryption hardware.
Unprotected Keys
By default, when an encryption key block is burned it is also read and write protected.
The --no-read-protect
and --no-write-protect
options will disable this behaviour (you can separately read or write protect the key later).
Note
Leaving a key unprotected may compromise its use as a security feature.
espefuse.py burn_key secure_boot_v1 secure_boot_key_v1.bin
Force Writing a Key
Normally, a key will only be burned if the efuse block has not been previously written to. The --force-write-always
option can be used to ignore this and try to burn the key anyhow.
Note that this option is still limited by the eFuse hardware - hardware does not allow any eFuse bits to be cleared 1->0, and can not write anything to write protected eFuse blocks.