lf-edge
[DO NOT MERGE] FDO client demo
Some things to enable an FDO demo which fills in /config/server and /config/root-certificate.pem using Fido Device Onboarding, plus a binary blob of the FDO client from Intel.
This images produced with this PR require that there be an FDO setup since the images do not include /config/server nor /config/root-certificate.pem. But the first three commits can be pushed to master at some point in time since they merely make EVE robust against /config/server and /config/root-certificate.pem not being initially present when the device boots (avoiding log.Fatals in such a case.)
Also, the pkg/pillar/fdo-alpine-3.16/linux-client is a binary blob and in due time it makes sense to either build that from source or pull it from e.g., docker hub.
Last but not least, in a production setup the manufacturer would create the secrets corresponding to the FDO ownership voucher in the TPM, and then the FDO client would read those. For the purposes of making the demo easier (and not rely on TPM clear) they are instead in pkg/pillar/fdo-alpine-3.16/data/
There is need to 1) create the FIDO vouchers on the device, 2) import them on the destination controller. Sure it is standard and good, but I have hard time seeing the benefits (for our use case) compared to implanting the countroler public key and onboarding them in a secure environment, because with FIDO now there is extra manual steps (importing/~~exporting~~ vouchers) to benefit from the mutual authentication.
There is need to 1) create the FIDO vouchers on the device, 2) import them on the destination controller. Sure it is standard and good, but I have hard time seeing the benefits (for our use case) compared to implanting the countroler public key and onboarding them in a secure environment, because with FIDO now there is extra manual steps (importing/~exporting~ vouchers) to benefit from the mutual authentication.
Correct, which is why this is just for a demo for now.
The benefit we would get (if/when the hardware manufacturer generates the vouchers and put the corresponding private key ib the TPM) is that we can have a single EVE image which is not yet tied to a particular controller (server and root-certificate.pem) but instead have FDO provide that.
If hardware manufacturers start doing that FDO work we can later expore using this for other aspects (such as side-loading application images etc).