tpm2_getekcertificate: add support to high range NV indexes

[loicsikidi]

Fixes #3435.

Note:

• The test case uses self-signed certificates because I didn't found a valid one in https://ekop.intel.com (e.g. RSA 3072 or ECC P384)

[JuergenReppSIT]

@loicsikidi your PR would change the behaviour of tpm2_getekcertificate for TPMs with certificates in the low and in the high range (e.g. Infineon SLB 9672). Instead of the low range certificates the high range certificates would be saved.
It would be better to implement the option -u pubkey which currently can't be used for certificates in the NV ram.

[JuergenReppSIT]

If you would change the lookup part as follows:

    ctx.rsa_ek_cert_nv_location = 0xffffffff;
    ctx.ecc_ek_cert_nv_location = 0xffffffff;

    for (i = 0; i < capability_data->data.handles.count; i++) {
        TPMI_RH_NV_INDEX index = capability_data->data.handles.handle[i];
        const ek_index_map *m = lookup_ek_index_map(index);
        if (!m) {
            continue;
        }

        if (m->key_type == KTYPE_RSA && index < ctx.rsa_ek_cert_nv_location) {
            LOG_INFO("Found pre-provisioned RSA EK certificate at %u [type=%s]", index, m->name);
            ctx.is_rsa_ek_cert_nv_location_defined = true;
            ctx.rsa_ek_cert_nv_location = m->index;
        }
        if (m->key_type == KTYPE_ECC && index < ctx.ecc_ek_cert_nv_location) {
            LOG_INFO("Found pre-provisioned ECC EK certificate at %u [type=%s]", index, m->name);
            ctx.is_ecc_ek_cert_nv_location_defined = true;
            ctx.ecc_ek_cert_nv_location = m->index;
        }
    }

it's ensured that the certificate would be written as previously. The high range certificates would only be written if no low level certificates exist. After your PR is merges I will add a PR with the -u option to enable saving the EK certificate based on the public EK.
I think that's a better solution than allowing e.g. four -o options to save all certificates.

[loicsikidi]

@JuergenReppSIT I've added your suggestion and one more test to attest that if there are >= 2 certs of the same type => the low range one must be returned.

Thanks for the feedback!

I wasn't aware that some TPMs have more than one EK cert from the same family 😅

[JuergenReppSIT]

@loicsikidi Thank you for the PR. I have already prepared the -u change.

[JuergenReppSIT]

@loicsikidi Sorry I was a bit hasty in approving the PR, because tests for the change I did require worked for me in my local docker imgages. The test getekcertificate.sh now fails with your current PR. I have to investigate what's the difference between your PR an my branch where the test runs without problems.

[loicsikidi]

@JuergenReppSIT I think that I've found the issue 💡 .

The last test is failing because there are 2 "eligible" EK certs in NVRAM but there is only one -o...

## Make sure that if there are several certificates of the same type, then the one belonging to low range has priority
openssl x509 -in ecc_ek_cert.bin -out ecc_low_range_ek_cert.der -outform DER
define_ek_cert_nv_index ecc_low_range_ek_cert.der $ECC_EK_CERT_NV_INDEX

tpm2 getekcertificate -o nv_ecc_ek_cert.der

diff nv_ecc_ek_cert.der ecc_low_range_ek_cert.der

ERROR:

WARN: Found 2 certficates on NV. Add another -o to save the ECC cert

My bad..., I'll push a fix 🚀

[loicsikidi]

I think that we can retry 💪

[JuergenReppSIT]

@loicsikidi Thank you for the fix.