EvictControl missing from new tpm2
frezbo opened this issue · 10 comments
legacy tpm2 had a evictcontrol
Line 1125 in f17b035
Or is that not needed anymore?
As the tpmdirect API is suppose to mirror the actual TPM API, it's missing it seems. This makes dealing with key hierarchies impossible(?) with the current API.
Thanks, I was wondering how to persist an SRK key
Yes, I'm dealing with the exactly the same problem trying to learn the new API :)
It's needed and welcome, please feel free to send a PR based on the structure of the other commands, and I'd be happy to prioritize review (because reviewing the 1:1 mapped spec-to-structs code is pretty straightforward). Thank you for trying out the new API!
<remove go-TPM hat, don TCG/TPM hat>
The reason EvictControl isn't yet available in the new API is that you don't actually need it, most of the time. Of course, if you are trying to plug in to an existing infra that expects, for example, a persistent RSA SRK, then you need it.
The reason I say you do not really need it:
EvictControl takes an existing object and stores it to TPM NV for convenience. Usually this is done on Primary Keys. The main reasons (besides avoiding another call to CreatePrimary/FlushContext) this is done:
- That most closely reflects how the SRK worked in TPM 1.2 (it was special, somebody had to make it)
- RSA Primary Keys can take a very long time to generate each time
If you're using ECC Primary Keys (which I would recommend), the CreatePrimary call will in some cases be faster than using the key out of NV flash memory.
All that said, PR to add EvictControl is completely welcome 😎
Right, because just using CreatePrimary with the SRK template should always give you the correct key regardless.
However, it seems like projects like systemd use EvictControl to ensure a known persistent key can be used for sessions. Is this one of the few valid use cases for EvictControl?
Depending on how you have the owner hierarchy password/policy set up, then the persisted key being present at the expected index could be an indicator of trust; however, you need owner auth to CreatePrimary, same as to EvictControl. I'm not familiar enough with how systemd is using the persisted SRK to comment further: I am used to environments where the owner auth is well-known and thus not a barrier to adversaries in the threat model.
Right, because just using CreatePrimary with the SRK template should always give you the correct key regardless.
However, it seems like projects like systemd use EvictControl to ensure a known persistent key can be used for sessions. Is this one of the few valid use cases for EvictControl?
I was also implementing the systemd flow in go, and hit by this, though v253 of systemd did not use an SRK at all
Right, because just using CreatePrimary with the SRK template should always give you the correct key regardless.
However, it seems like projects like systemd use EvictControl to ensure a known persistent key can be used for sessions. Is this one of the few valid use cases for EvictControl?
systemd/systemd#26185I was also implementing the systemd flow in go, and hit by this, though v253 of systemd did not use an SRK at all
okay, the reason probably systemd persists it is due to that fact that falls back to RSA if ECC is not supported. Otherwise it doesn't seem no reason to persist an ECC key
Regardless of if systemd demands it, a PR adding EvictControl here would still be quite welcome (maybe someone else has a use case) :)