Open tuminoid opened 2 months ago
This is by design, it is in the specification. The trust comes from the Endorsement Key (EK) certificate from the TPM, which is an immutable certificate signed by the manufacturer. The agent itself is not trusted. Feel free to join the #keylime channel in CNCF slack instance to ask this kind of question: https://slack.cncf.io/
Sorry for the incomplete documentation. Please consider contributing.
This is by design, it is in the specification. The trust comes from the Endorsement Key (EK) certificate from the TPM, which is an immutable certificate signed by the manufacturer. The agent itself is not trusted.
Thanks for the answer, I had a hunch it could be like that. Would you mind adding the link to this specification? I'm not seeing any in your website/repo.
Feel free to join the #keylime channel in CNCF slack instance to ask this kind of question: https://slack.cncf.io/
I will, thanks.
This is by design, it is in the specification. The trust comes from the Endorsement Key (EK) certificate from the TPM, which is an immutable certificate signed by the manufacturer. The agent itself is not trusted.
Thanks for the answer, I had a hunch it could be like that. Would you mind adding the link to this specification? I'm not seeing any in your website/repo.
Good point, if you cannot find the specification, this is a problem.
@THS-on @maugustosilva @galmasi Could you please help here?
The communication model with what certs are used are documented in the RHEL documentation, but not int the upstream docs (https://docs.redhat.com/de/documentation/red_hat_enterprise_linux/9/html/security_hardening/assembly_ensuring-system-integrity-with-keylime_security-hardening#con_how-keylime-works_assembly_ensuring-system-integrity-with-keylime). That part of Keylime is still covered by the original paper: https://www.ll.mit.edu/sites/default/files/publication/doc/2018-04/2016_12_07_SchearN_ACSAC_FP.pdf
As @ansasaki already mentioned the agent is untrusted. We introduced mTLS for the tenant/verifier and agent communication a while back. It would be rather simple to migrate also to TLS between agent and registrar, just no one yet has written an enhancement and implemented it.
Agent registers itself via insecure http, not via https. This seems to be hardcoded on L108, despite Agent MTLS is configued to be
true
.Since Securing Keylime is completely TBD, and most of the docs do not recognize
rust-keylime
at all, I'm at a loss if this is by some limitation, or by design, or is this just an oversight in rust-keylime as its catching up to old keylime agent? Or maybe I missed something? :wink: