Agent registers via insecure http

[tuminoid]

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? 😉

INFO  keylime_agent::registrar_agent > Requesting agent registration from http://<ip>:8890/v2.2/agents/7b32f0fc13de4a841ddcf808e02c8c1481f6741f51240c4e21038980d5be5819 for 7b32f0fc13de4a841ddcf808e02c8c1481f6741f51240c4e21038980d5be5819
INFO  keylime_agent                  > SUCCESS: Agent 7b32f0fc13de4a841ddcf808e02c8c1481f6741f51240c4e21038980d5be5819 registered
INFO  keylime_agent::registrar_agent > Requesting agent activation from http://<ip>:8890/v2.2/agents/7b32f0fc13de4a841ddcf808e02c8c1481f6741f51240c4e21038980d5be5819 for 7b32f0fc13de4a841ddcf808e02c8c1481f6741f51240c4e21038980d5be5819
INFO  keylime_agent                  > SUCCESS: Agent 7b32f0fc13de4a841ddcf808e02c8c1481f6741f51240c4e21038980d5be5819 activated
INFO  keylime_agent                  > Listening on https://127.0.0.1:9002/

[ansasaki]

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.

[tuminoid]

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.

[ansasaki]

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?

[THS-on]

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.