Add signed bootloader verification chain

[kwsantiago]

Verify firmware signatures at boot to prevent malicious reflash.

[kwsantiago]

Implementation Notes

ESP-IDF Secure Boot v2 Approach

ESP-IDF provides hardware-backed secure boot for ESP32-S3:

CONFIG_SECURE_BOOT=y
CONFIG_SECURE_BOOT_V2_ENABLED=y
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_APPS_RSA_SCHEME=y

Key Components:

1. eFuse-stored public key digest - Burned once, cannot be changed
2. RSA-3072 or ECDSA-P256 signatures - On bootloader and app
3. Rollback protection - Prevents downgrade to older (potentially vulnerable) firmware

Signing Workflow

# Generate signing key (keep secure!)
espsecure.py generate_signing_key --version 2 secure_boot_signing_key.pem

# Sign bootloader
espsecure.py sign_data --version 2 --keyfile secure_boot_signing_key.pem \
    --output bootloader-signed.bin build/bootloader/bootloader.bin

# Sign application
espsecure.py sign_data --version 2 --keyfile secure_boot_signing_key.pem \
    --output app-signed.bin build/keep.bin

Key Management Considerations

• Offline signing key - Never on development machines or CI
• Hardware Security Module (HSM) - Ideal for production signing
• Key ceremony - Document key generation and storage procedures
• Multiple signers - Consider threshold signing for the signing key itself

Rollback Protection

CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE=y
CONFIG_BOOTLOADER_APP_ANTI_ROLLBACK=y
CONFIG_BOOTLOADER_APP_SECURE_VERSION=1

Increment SECURE_VERSION with each release to prevent downgrade attacks.

Flash Encryption (Complementary)

Consider pairing with flash encryption to protect firmware at rest:

CONFIG_SECURE_FLASH_ENC_ENABLED=y
CONFIG_SECURE_FLASH_ENCRYPTION_MODE_RELEASE=y

Testing Strategy

1. Test in development mode first (allows reflashing)
2. Validate full chain before burning eFuses
3. Keep test devices separate from production devices
4. Document recovery procedures (there is no recovery after eFuse burn)

References

• ESP-IDF Secure Boot v2 Guide
• Flash Encryption