Feature request: output EK during swtpm_setup

[osresearch]

Describe the bug
Extracting the EK from a new swtpm environment is complex and error prone.

To Reproduce
Steps to reproduce the behavior:

1. Create the TPM state with the EK:

        swtpm_setup \
                --tpm2 \
                --createek \
                --display \
                --tpmstate "./tpmdir" \
                --config /dev/null

2. Start a local swtpm to serve from this state

        swtpm socket \
                --tpm2 \
                --flags startup-clear \
                --tpmstate dir="./tpmdir" \
                --server type=tcp,port=9998 \
                --ctrl type=tcp,port=9999 \
                --pid file="/tmp/swtpm.pid" &

3. Avoid racing since swtpm isn't ready to serve immediately

        sleep 1

4. Use tpm2-tools to read the EK public structure:

        TPM2TOOLS_TCTI=swtpm:host=localhost,port=9998 \
        tpm2 createek \
                -c /tmp/ek.ctx \
                -u ek.pub

5. Shutdown the swtpm process and clean up temp files

        kill `cat /tmp/swtpm.pid`
        rm /tmp/swtpm.pid /tmp/ek.ctx

6. That's a lot of steps and hard to parallelize since it requires assigning ports and PIDs to background processes, plus there is a timing race with starting the background swtpm (and --daemon doesn't seem to work? the process exits immediately)

Expected behavior
swtpm_setup --display would print the EK public structure or have an option to write it somewhere. This is to allow an out-of-band delivery of the EK to an attestation server for virtual machines, similar to how GCP vTPM works.

Desktop (please complete the following information):

• OS: Ubuntu
• Version: 20.04

Versions of relevant components

• swtpm: ab40d27
• libtpms: d00c3b27852038cf1867dd47d8a11976b5ea3bab
• openssl:
• gnutls:
• ...:

[stefanberger]

You can have the output written into a log file and then grep for the EK keys. But it's also possible to grep for the EK keys like so:

swtpm_setup --tpm2 --create-ek-cert --tpm-state ./ --overwrite | sed -n 's/.*--ek \([^ ]*\).*/\1/p'
d310625d411b423c22d7a8b49eb0bbc23ced1ef49dc8640dcafafe25f30f81d6dfb206f45aab02f77eb6dead8dde722bc545c0aafa064e574a1b9d8da7b32cd0b31eb399256700a8c54e86d987c8dffae08024fb765137f2b15cd98bcbb4a098ea9779896d2894c079445141177915f5908cd4fe61e939e486d6119210b10353ac59f26a02241bf7177b0db7254eb7eb40de1add8c9c1abcde2bd5b5bb96164099bdeae53e1f5361fe8cd499295405abd4ac0acddeb9e49a7a747ea55848677dc4545c924656587555fb07a97b5b6b6c17f349738409e7ce4c86366fa5c5e27834358b652bbab3642b07746d5f56fe0bc1e21d81b40e226f68d611bcf6f7056f
x=bab66c4d52afe9c7b5eb2c6547337ad50e9cef4abe78ba9a8d4153f0010f27839eed1c61d2fcec196be6398d474dc067,y=b96aff9387ee8fe485b05e998f993f012831cea80d6afa50c6697a09fc7acecf9f6ed685ac97592872f07211978662c4,id=secp384r1

So it's not like this cannot be done today. What you get is the modulus only and the x and y coordinates and type of curve for an EC key.

[stefanberger]

@osresearch I now opened PR #466 . Please check it out and give it run.

> mkdir -p foo/bar
> ./src/swtpm_setup/swtpm_setup --tpmstate ./foo --create-ek-cert --overwrite --write-ek-cert-files ./foo/bar --rsa-keysize 2048 --tpm2 --allow-signing --create-platform-cert
> ls -l foo/bar/
total 8
-rw-r-----. 1 stefanb stefanb 1016 Jun 17 14:19 ek-rsa2048.crt
-rw-r-----. 1 stefanb stefanb  842 Jun 17 14:19 ek-secp384r1.crt

I also want to point out at this point that I won't always react to 'feature requests' but do expect others to contribute to swtpm as well.

[stefanberger]

@osresearch Did you give it a try?

[stefanberger]

So my PR is ready to be merged and I think it does what it is supposed to do.

However, I want to point out that there's a reason why swtpm_setup has the configuration script that configure it to call swtpm-localca. The reason for this is that there could be a remote/centralized CA for which swtpm_setup could invoke the client tool. The client would talk to that centralized CA which could keep track of all the platform and EK certs it ever issued.