Repository navigation
seal: secrets at rest under a chip-derived key; the partition table where the build puts it - #2
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nd to its key name, a fresh nonce per write) under a key the chip derives and never stores; hal::seal_key takes it from the HMAC peripheral and an eFuse key block (feature seal-hmac). A board provisioned in the clear is sealed where it lies; with no key nothing pretends. partitions: the table where the build puts it (ESP_BOOTLOADER_ESP_IDF_CONFIG_PARTITION_TABLE_OFFSET, the setting esp-bootloader-esp-idf reads), read through the cache under flash encryption -- the secure-boot bootloader does not fit under 0x8000 on the C6. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…g in place (NVS keeps a rewritten value's old bytes until its page is erased) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ttimmahlax
pushed a commit
that referenced
this pull request
Oct 16, 2026
Sealed secrets at rest: mid-core's seal::SealedKv; mid-esp's hal::seal_key (feature seal-hmac) and the partition table read where the build put it, through the cache under flash encryption (#2). The set moves together. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
rusty_esp_mid-core::seal::SealedKv— aKvthat seals every value with AES-256-GCM: a fresh nonce per write, the value's own key name as additional data (a sealed value moved under another name does not open). A value written in the clear before sealing still reads, andseal_in_placeseals it where it lies. Built with no key, it passes values through and says so (sealing()).rusty_esp_mid-esp::hal::seal_key(featureseal-hmac) — the sealing key from the HMAC peripheral over an eFuse key block burned forHMAC_UP: software never reads the key, and a chip without one answersNone.hal::partitions— the table atESP_BOOTLOADER_ESP_IDF_CONFIG_PARTITION_TABLE_OFFSET(the setting esp-bootloader-esp-idf reads, so the two cannot disagree), and read through the cache under flash encryption, where it is ciphertext on the flash. A secure-boot + flash-encryption bootloader is 36,800 B on the C6 and does not fit under0x8000.Why
Flash encryption covers app slots, not an NVS-format partition, so a device key and a network passphrase sat in the clear on a dumped flash.
Checked
6 seal tests on the host; the name binding broken on purpose and caught. Built into a C6 firmware; on a chip with no key burned it runs with
secrets=plain. Not yet run on a chip with the HMAC key burned (that needs a sacrificial board).Also carries
75e4571(gen_gtable), an earlier unpushed commit onmain.🤖 Generated with Claude Code