Hey everyone. I was reading the docs and saw we can use either software-based sealing (tied to the enclave's launch hash) or TPM sealing. I was using software for a while but just switched my test setup over to the TPM method.
The 'aha' moment for me was realizing what happens during an enclave update. With software sealing, the launch hash changes after a code update, so the old sealed data is gone forever. That's fine for ephemeral stuff, but I have a few keys I really don't want to regenerate and re-provision every single time. Using the TPM (with a stable PCR policy) means my keys survive enclave updates, as long as the TPM itself is the same. It just feels more permanent for the things that should be.
Was this the main reason others moved to TPM sealing too? Or are there other big advantages I'm missing? Grateful for this community, by the way. The docs are great but hearing from people actually running this stuff is even better.
jen
Yeah, that was my main reason for looking into it too. The update problem is a killer for anything that needs to stick around.
But I got hung up on the PCR policy part. How do you pick which PCRs to use? I saw you mentioned "stable" ones. I'm worried about picking a PCR that changes after, like, a BIOS update and then getting locked out. Is that a real risk?
"Stable" PCRs? Good luck. PCR0 changes on every microcode update. PCR7 changes if you so much as look at your Secure Boot settings funny.
You're not wrong to be worried. It's a real risk. Picking a PCR policy feels like gambling on what your vendor won't update next.
Honestly, this is why I just keep critical keys on a separate, air-gapped pi zero. No PCRs to worry about. All this complexity for what?
Oh wow, that's a really sobering point about the vendor updates. I hadn't even considered microcode or BIOS updates changing the PCRs. That sounds like a nightmare waiting to happen, being locked out of your own keys because of a security patch.
So, following your point about the Pi Zero, is the takeaway that TPM sealing is maybe only good for things you're okay losing? Like, use it for stuff where the convenience of automatic unsealing is nice, but you can afford to manually restore from a backup if a PCR change bricks it? That seems less magical than I was hoping for.
It's all so much more fragile than I imagined. Makes me want to go re-read my motherboard's update notes to see how often they actually touch those firmware components.
You're right to check those notes. In my experience, vendor firmware updates are rarer than you think for a stable server, but they do happen.
That's why a backup unsealing strategy is key. I treat my TPM like a convenient cache, not the single source of truth. The real, recoverable copy of a critical key is still stored encrypted elsewhere (like on that pi zero). The TPM just saves me from manually loading it on every boot or enclave restart.
It's less "fragile" and more "layered." The magic is in the automation, not in pretending the PCRs are immutable stone tablets.
PCR0 is basically a promise your vendor will break. Picking PCRs for a "stable" policy feels like reading tea leaves.
Here's my rule: only include PCRs for components *you* control and update deliberately. That usually means PCR 8+ (the OS/kernel measurements), because you orchestrate those updates through your pipeline. Let your PCR policy reflect your actual change control, not some vendor's opaque update schedule.
It's a real risk, but a manageable one if you treat the TPM as a caching layer, not a vault. Backup unseal keys are still mandatory.
mj
Totally agree on PCRs 8+. That's the only sane control plane you have.
But even there, you can paint yourself into a corner if you're not careful with the policy syntax. If you use `TPM2_PolicyPCR` with a banked list of PCR values, a kernel security update locks you out until you rebuild the policy. What you want is `TPM2_PolicyAuthorize`, so you can sign new PCR values with a stable key and let the TPM accept them. It turns a "hard" policy into a "soft" one you can manage.
Otherwise you're just trading vendor unpredictability for your own ops team's update schedule. Same problem, smaller blast radius.
kim out
Hey, I'm in the exact same spot. That 'aha' moment about updates wiping sealed data was what pushed me to experiment with TPM too. I was tired of manually shuffling keys after every minor agent update in my test lab.
But man, reading down the thread about PCR instability is a bit of a wake-up call. I think I made the right move for convenience, but I'm suddenly very glad my setup is just for learning and nothing truly critical yet. I'm treating this whole thing as a fancy, automated cache now, not a permanent vault.
- Tom