ESP32-S3 Secure Boot v2 and the GPLv3 Anti-Tivoization Clause: A Forensic Audit of eFuse Lockdown

You get an IoT sensor node or edge gateway that runs a GPLv3 userspace. You rebuild the bootloader, flash it, and the ESP32-S3 sits there dead. That is not a bug. Somebody made a choice—and that choice might have legal teeth. The chip’s secure boot v2 and flash encryption engine lean on a chain of one-time-programmable eFuse bits. Burn the right ones and the silicon will only execute firmware signed by a specific private key. The question engineers, compliance officers, and procurement teams need to answer is blunt: when does flipping those eFuses turn a security feature into an installation restriction that trips GPLv3 Section 6?

This piece walks through the ESP32-S3 eFuse layout, the secure boot v2 signing flow, and the exact commands that tell you whether a device sitting on your bench can accept your own GPLv3-compliant firmware. I am not going to reprint the GPLv3 text. I am going to show you which eFuse bits matter, how to read them, and how to write an RFQ clause that keeps user freedom intact without demanding a completely unlocked chip from your vendor.

Reading the eFuse Block: What espefuse.py Tells You

Espressif lays out the eFuse map in the ESP32-S3 Technical Reference Manual, Chapter 12. The chip packs 4 Kbits of eFuse memory split into blocks. Three blocks matter for our purposes: BLOCK0 (system parameters), BLOCK_KEY0 through BLOCK_KEY5 (key storage), and the read/write protection bits tied to them. The tool espefuse.py (shipped with esptool) dumps the current state. On a device fresh from a contract manufacturer, run:

espefuse.py --port /dev/ttyUSB0 summary

The output spits out fields like SECURE_BOOT_EN, SECURE_BOOT_AGGRESSIVE_REVOKE, FLASH_CRYPT_CNT, and the per-key-block PURPOSE fields. A device set up for secure boot v2 with flash encryption usually shows:

• SECURE_BOOT_EN = 1 (burned, irreversible)
• BLOCK_KEY0_PURPOSE = SECURE_BOOT_DIGEST0 (holds the SHA-256 digest of the public key)
• BLOCK_KEY1_PURPOSE = XTS_AES_128_KEY or similar for flash encryption
• FLASH_CRYPT_CNT = a value that, when odd and maxed, permanently enables encryption

The forensic line that matters is between reversible and permanently enabled states. Espressif’s documentation uses the phrase “permanently enable” for certain eFuse writes. Once FLASH_CRYPT_CNT hits its maximum odd value (typically 7 on ESP32-S3), flash encryption cannot be turned off. Once SECURE_BOOT_EN is burned, secure boot stays on. The chip will refuse to boot any firmware image not signed by the key whose digest lives in BLOCK_KEY0.

Secure Boot v2 Signing Workflow: Where the Lock Engages

Secure boot v2 on ESP32-S3 uses an RSA-3072 or ECDSA-256 key pair. The entity that signs firmware images holds the private key. The public key digest gets burned into eFuse. The boot ROM checks the signature on the bootloader image before executing it. The bootloader then verifies the application partition before jumping to it. Two-stage verification chain.

If a device lands on your desk with secure boot enabled and nobody hands over the private key, you cannot replace the bootloader. You cannot replace the application firmware either, unless the bootloader’s verification logic allows unsigned application partitions—and secure boot v2, by design, does not. The chip boot-loops or falls back to a recovery mode that still demands a signed image.

This is where GPLv3 Section 6 enters the frame. Section 6 says that if a “User Product” conveys GPLv3-covered software, the installation information must be supplied so a user can install and run modified versions. The anti-tivoization clause zeroes in on hardware that checks for a valid cryptographic signature and refuses to run modified software. The FSF’s GPLv3 rationale document calls out this pattern by name.

The legal question is not whether secure boot counts as a security feature. It is whether the device, as shipped, blocks the user from exercising the freedom to modify and run the GPLv3-covered software. Withhold the private signing key, burn the eFuses so the user cannot swap in their own key, and you have tivoized the device.

Testing Re-Flashing Rights on Your Bench

To figure out whether a specific ESP32-S3 device respects GPLv3 Section 6, run this sequence:

1. Dump eFuse summary. Note the values of SECURE_BOOT_EN, SECURE_BOOT_AGGRESSIVE_REVOKE, and FLASH_CRYPT_CNT.
2. Check key block purposes. If BLOCK_KEY0_PURPOSE reads SECURE_BOOT_DIGEST0, secure boot is active. If any key block purpose shows XTS_AES_128_KEY or XTS_AES_256_KEY, flash encryption is active.
3. Attempt to read key blocks. Use espefuse.py --port /dev/ttyUSB0 dump. If the read protection bits are set, the key material is not extractable. That is expected for security, but it also means you cannot pull the public key digest to verify which key the chip demands.
4. Build a minimal GPLv3 bootloader. Grab ESP-IDF v5.1 or later, configure a fresh signing key, and attempt to flash via esptool.py write_flash. If the chip refuses to boot, you are holding a tivoized device.
5. Check for key revocation. If SECURE_BOOT_AGGRESSIVE_REVOKE is set, the chip can permanently revoke keys, making recovery even harder.

On a device I audited from an Indian EMS provider shipping white-label industrial gateways, the eFuse summary showed SECURE_BOOT_EN=1, FLASH_CRYPT_CNT=7, and every key block read-protected. The vendor’s “open source compliance” package included kernel sources but no signing key, no script to regenerate the bootloader, and zero documentation of the eFuse configuration. The device was GPLv3 non-compliant.

When Does Secure Boot Cross the Line? A Decision Framework

Not every use of secure boot is a GPLv3 violation. The hinge is who controls the signing key and whether the user can substitute their own verification material. Here is a decision framework for engineers and procurement teams:

The framework makes one thing plain: the bare presence of secure boot is not the violation. The violation happens when the eFuse configuration and key management practices combine to stop the user from running modified GPLv3 software. Espressif’s hardware gives you the mechanisms to build both compliant and non-compliant setups. The device manufacturer makes the choice.

Procurement Language: Writing an RFQ Clause That Preserves Re-Flashing Rights

Enterprise security teams often mandate secure boot. That requirement can sit alongside GPLv3 compliance if the contract spells out key handover and eFuse configurability. Below is a draft clause for an RFQ or supply agreement, written in language that procurement officers and contract manufacturers can actually operationalize:

Firmware Freedom and Re-Flashing Clause. If the delivered device includes software licensed under GPLv3 or any license containing an anti-tivoization provision, the Supplier shall: (a) provide the complete corresponding source code as required by the license; (b) provide the private cryptographic signing key used for secure boot verification, or alternatively, ship the device with secure boot disabled or with the eFuse key block writeable and documented such that the Buyer can burn its own public key digest; (c) document the eFuse configuration, including the state of SECURE_BOOT_EN, FLASH_CRYPT_CNT, and all key block PURPOSE and read/write protection bits; (d) warrant that the device will accept and execute firmware images signed by the Buyer’s key after following the documented procedure. The Supplier shall not burn SECURE_BOOT_AGGRESSIVE_REVOKE unless the Buyer explicitly requests it in writing and acknowledges the GPLv3 implications.

This clause does not force the vendor to ship an unlocked device. It forces the buyer to retain the ability to install modified software. For plenty of industrial applications, the buyer is the end user and the “User Product” definition in GPLv3 applies straight. For devices that are components in a larger system, the analysis may shift, but the procurement language still protects downstream users.

The Political Economy of the eFuse: Who Controls the Toolchain, Who Controls the Device

The ESP32-S3 is a mass-market chip. Espressif ships the ESP-IDF framework under Apache 2.0, which is permissive and does not trigger anti-tivoization. The GPLv3 software that runs on top—often in the application layer, sometimes in the bootloader if a vendor pulls in U-Boot or a GPLv3 bootloader—is what creates the obligation. The silicon itself is agnostic.

What I keep seeing in the Indian contract manufacturing ecosystem is a pattern: an OEM designs a gateway around the ESP32-S3, pulls in GPLv3 userspace components (frequently from OpenWrt or a Debian-derived rootfs), enables secure boot because a corporate buyer’s checklist demands it, and then ships the device with no signing key and no documentation. The corporate buyer’s security team checks the box. The GPLv3 violation stays invisible until somebody tries to fix a field bug and discovers the boot ROM rejects their image.

This is not a technical problem. It is a procurement problem. The security requirement got written without any awareness of software freedom obligations. The fix is not to disable secure boot everywhere. The fix is to write requirements that specify who holds the key.

When I teach this material to embedded teams, I often point them toward resources that help structure technical documentation clearly—something as simple as a well-organized style guide can make the difference between a compliance package a contract manufacturer can follow and one that gets ignored. The Authors Guild’s AI Best Practices for Authors offers a useful model for how to structure technical authorship so the intent survives translation across supply chain tiers. Similarly, Purdue OWL’s Creative Writing Introduction provides structural principles that apply equally to technical documentation: clarity of audience, consistency of terminology, and explicit statement of constraints. These are not legal resources, but they are writing resources that improve the quality of compliance documentation.

Maintenance and Longevity: What Happens When the Key Holder Disappears

There is a second-order problem that gets less airtime. Suppose a vendor ships a GPLv3-compliant device, hands over the signing key, and then goes out of business. The user has the key and can sign firmware indefinitely. That is the compliant scenario. Now suppose the vendor ships a device with secure boot enabled, provides the key, but also burns SECURE_BOOT_AGGRESSIVE_REVOKE. A future firmware update could revoke the user’s key and lock the device permanently. The user’s freedom hangs on the vendor’s continued goodwill.

The eFuse SECURE_BOOT_AGGRESSIVE_REVOKE bit enables a revocation mechanism that a signed firmware image can trigger. Once triggered, the chip permanently revokes the key digest in BLOCK_KEY0 and will not boot images signed with that key. If the vendor pushes an update that revokes the user’s key and then ceases operations, the device is bricked for any purpose other than running the last vendor-signed image. That is a longevity risk procurement teams should evaluate explicitly.

On the ESP32-S3, the aggressive revocation mechanism is documented in the TRM Section 12.3.2. The eFuse bit sits in BLOCK0, byte 14, bit 1. Check it with:

espefuse.py --port /dev/ttyUSB0 summary | grep AGGRESSIVE_REVOKE

If that bit is burned, the device carries a time bomb. The only mitigation is contractual: prohibit the vendor from burning it unless the buyer explicitly accepts the risk.

Unsloppy Documentation as a Compliance Tool

One of the recurring failures I see in GPL compliance enforcement is documentation that is technically accurate but organizationally unusable. A tarball of source code with no build instructions, no eFuse configuration summary, and no signing script is not “corresponding source” in any meaningful sense. The GPL requires scripts used to control compilation and installation. For an ESP32-S3 device with secure boot, the signing script and the eFuse burning procedure are part of the installation information.

Writing that documentation so a contract manufacturer’s NPI engineer can follow it six months later demands a level of clarity most embedded teams never invest in. I have found that applying the same structural discipline good creative writing workshops teach—explicit audience identification, scenario-based instructions, and avoidance of assumed knowledge—produces compliance packages that actually survive supply chain handoffs. The concept of how Unsloppy fits the writing workflow is not about literary flourish; it is about writing installation instructions that a technician in a different time zone, with a different primary language, can execute without ambiguity. That is what GPL compliance demands and what most vendors fail to deliver.

Conclusion: Audit Your eFuses Before You Sign the PO

The ESP32-S3 is a capable chip. Its security features are well-documented and, used correctly, do not conflict with software freedom. The conflict shows up when manufacturers burn eFuse bits that permanently lock the chip to a key they refuse to share, while shipping GPLv3 software on top. That configuration is a GPLv3 Section 6 violation, and you can detect it with a five-minute espefuse.py summary command.

For engineers evaluating a vendor sample: dump the eFuses. If SECURE_BOOT_EN is burned and the key block is read-protected, ask for the signing key. If the vendor cannot or will not provide it, the device is tivoized. For procurement officers: add the firmware freedom clause to your RFQ. It costs nothing to require key handover or eFuse writeability, and it prevents a legal and operational liability that will surface the first time your field team needs to patch a vulnerability in a GPLv3 component.

Hardware that you cannot inspect, modify, or repair is hardware that controls you. The eFuse bits on an ESP32-S3 are the physical embodiment of that control. Read them before you buy.