Registration of agent fail, when keylime use non-default algorithm

[Koncpa]

Environment

• OS / version: fedora35
• Processor architecture: x86_64
• TPM Manufacturer: swtpm
• Keylime version: keylime-upstream-version

Description

When I use different encryption and signing algorithm in agent.conf, than default RSA the agent cannot be registered and registration fail. I used ECC instead of RSA for encryption and ECSCHNORR instead of RSASSA for signing.

RFE-Keylime tests

Expected behavior vs. actual behavior

Agent will succesfully register vs. registration of agent fail.

Steps to reproduce problem:

1. Setup swtpm on machine
2. Install keylime package
3. Change in agent.conf encryption algorithm to tpm_encryption_alg = ecc and signing algorithm to tpm_signing_alg = ecschnorr
4. Run keylime verifier,registrar,agent and wait for registration of agent.

Relevant logs

Feb 03 10:22:58 ci-vm-10-0-136-178.hosted.upshift.rdu2.redhat.com keylime_agent[6013]: WARNING:esys:src/tss2-esys/api/Esys_NV_ReadPublic.c:309:Esys_NV_ReadPublic_Finish() Received TPM Error
Feb 03 10:22:58 ci-vm-10-0-136-178.hosted.upshift.rdu2.redhat.com keylime_agent[6013]: ERROR:esys:src/tss2-esys/esys_tr.c:209:Esys_TR_FromTPMPublic_Finish() Error NV_ReadPublic ErrorCode (0x0000018b)
Feb 03 10:22:58 ci-vm-10-0-136-178.hosted.upshift.rdu2.redhat.com keylime_agent[6013]: ERROR:esys:src/tss2-esys/esys_tr.c:320:Esys_TR_FromTPMPublic() Error TR FromTPMPublic ErrorCode (0x0000018b)

Output of logs can be found in /var/tmp/limeLib after run, when you reproduce by first approach. Should be here agent.log and also registrar.log.

[THS-on]

Can you check if swtpm can load certificates for ECC, because it looks like that the NV index where the ECC certificate is normally located does not exist?

Besides that, the error handling if reading the EK fails should be improved.

[Koncpa]

Sorry for the later response.

There is output of nv-indexes:

[root@pkoncity-basic-attestation-on-localhost]# tpm2_getcap handles-nv-index
- 0x1C00002
- 0x1C00016
- 0x1C08000

It's look like that NV indexes are here. I assume, that ECC cert should be in 0x1C00016. This index I'm able to manually parse and get EK cert.

[THS-on]

Hmm that's interesting, thank you for checking. It might be an issue with the upstream library and not us.

Yes the index 0x1C00016 is correct according to https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_EKCredentialProfile_v2p4_r3.pdf

[THS-on]

Ok the issue is that swtpm uses the P-384 curve for ECC and the rust bindings and tpm2-tools use P-256. The question is if we need to make this parameter configurable or if we convince both to only use one curve.

[Koncpa]

Hmm what do you think will be more effective? How difficult would it be to implement if we decided to handle this on the keylime side using a configurable parameter? If it would be too difficult and unnecessary, we can try to open a discussion about the replaced P-256, which offers lower safety even though the performance is better.

[THS-on]

The idea is probably going to be to provide an "auto" option that chooses the best curve (by e.g. checking if we have an EK certificate for that) and a way to choose for people that know what they are doing.

This issue is currently blocked by: parallaxsecond/rust-tss-esapi#397

[THS-on]

We now have the code to handle this in the TSS bindings. Once the next version is released, I'll look into how we implement it in Keylime.

[Koncpa]

Any news regarding to this? @THS-on

[ansasaki]

We finally have the tss-esapi version 0.7.4 as dependency, which unblocks this. If @THS-on don't have the time to work on this I'll try to find some time to dedicate to this issue.

[THS-on]

@ansasaki that would be nice!

Note that there was a bug in create_ak for ECC keys in some versions, that was only fixed last week: parallaxsecond/rust-tss-esapi#464

[THS-on]

@ansasaki have you had the chance to look at this? We at least should make sure that some ECC options work

[ansasaki]

@THS-on IIRC, the fix you introduced in rust-tss-esapi was never released in any stable release. We are still waiting it to be released.

[THS-on]

Right the fix is only in part of the 8.0.0 alpha branch. Do you think this worth trying to ask to backport it into a stable branch?

[ansasaki]

Right the fix is only in part of the 8.0.0 alpha branch. Do you think this worth trying to ask to backport it into a stable branch?

Yes, I think that could unblock us in this front. I'm also interested in enabling ECC when possible