You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can currently use discrete TPM chips on ARM and Intel/AMD, and on Intel/AMD that transparently support firmware TPMs (since they look the same to Linux user space), but not firmware TPM on ARM.
We do build the OP-TEE firmware for ARM (in pkg/optee-os) so we have the infrastructure to run fTPM firmware. But need the actual firmware built, and perhaps more challenging, figure out what is the manufacturing/install workflow which ensures that each fTPM gets its unique root of trust.
The text was updated successfully, but these errors were encountered:
Run fTPM as a regular TA is not a big deal, we have the infrastructure almost ready for devices running OPTEE-OS. However, in this approach the fTPM is initialized from EVE, so we must evaluate the security aspects to ensure there is no attack surface between boot and EVE initialization.... fTPM uses regular encrypted files under the filesystem for key storage, we could use /persist, for instance...
Another approach would be run fTPM as a PTA, i.e., directly within OPTEE-OS. In this way fTPM would be initialized at early boot along with OPTEE-OS. However, the main issue with this approach is the storage device. I think the only way would be use the RPMB secure storage, but it must be provisioned in advance and it's only available for eMMCs.... OPTEE-OS used to allow write files from Secure to Normal World to a specific place (/data/tee), but AFAIK this support was removed in favor of security...
We can currently use discrete TPM chips on ARM and Intel/AMD, and on Intel/AMD that transparently support firmware TPMs (since they look the same to Linux user space), but not firmware TPM on ARM.
We do build the OP-TEE firmware for ARM (in pkg/optee-os) so we have the infrastructure to run fTPM firmware. But need the actual firmware built, and perhaps more challenging, figure out what is the manufacturing/install workflow which ensures that each fTPM gets its unique root of trust.
The text was updated successfully, but these errors were encountered: