RA Chain of Trust

[shirinebadi]

I want to implement an attestation service in OP-TEE that establishes a chain of trust. Using ATF-A, I can ensure secure boot up to OP-TEE. So, how my service forms part of the TEE’s secure boot? e.g. I implement it as a PTA.

[shirinebadi]

Hi. Does my question make sense and has an explanation? I would appreciate your help.

[etienne-lms]

Hi @shirinebadi, Want do you want to attest? The OP-TEE core itself (or equivalently a/some PTA service(s) exposed by OP-TEE core)? A trusted application hosted in OP-TEE secure userland? A non-secure application running in non-secure userland world? Or maybe something else...

[shirinebadi]

I want to attest a TA in TEE user-space.

[etienne-lms]

There is an OP-TEE core service called the attestation PTA that is designed for that purpose: core/pta/attestation.c, pta_attestation.h. OP-TEE test implements some example of use: see xtest regression_1037. I think https://github.com/OP-TEE/optee_os/issues/6921 will also interest you.

[shirinebadi]

I see. My concern is regarding Chain of Trust. I'm using ATF-A to ensure secure boot of TEE, but how should I ensure the authenticated boot of Attestation service? Does ATF-A ensures it? I can't understand how chain of trust should work.

[etienne-lms]

I guess I misunderstood your initial question. I hope the below is more accurate.

As you stated, OP-TEE core image is authenticated at boot time by TF-A based on an embedded public key provisioned in the device (e.g. some OTP fuses). See porting_guidelines.html#root-and-chain-of-trust in OP-TEE documentation.

Authentication of TAs loaded by OP-TEE in the secure userspace depends on how the TA is embedded in the system. In any cases, it is based on the assumption OP-TEE has been authenticated (e.g. by TF-A boot stage) and the chain of trust has delegated to OP-TEE the authentication of the TAs.

• a TA image can be stored in OP-TEE core image, see so-called early-TA (the name my be confusing) in OP-TEE documentation. In this case, the TA is authenticated by TF-A as part of OP-TEE image, at boot time.
• a TA image can be stored in a Linux OS filesystem, see REE FS TA in OP-TEE documentation. These TAs are signed for authentication. The TA authentication public key is stored in OP-TEE core image (see TA_PUBLIC_KEY in mk/config.mk, or see TA subkeys). OP-TEE can support rollback protection of such TA version. OP-TEE can also provide encryption of TAs stored in the REE filesystem.
• a TA image can be installed in OP-TEE secure storage, see Secure storage TA in OP-TEE documentation. These TAs, when installed in OP-TEE secure storage, as authenticated using the scheme used for REE FS TAs. OP-TEE secure storage itself is a bit more complex, see also secure_storage in OP-TEE documentation.

When a client opens a session towards a TA (identified by its UUID), OP-TEE core looks for the related TA image in the below priority order:

• if the UUID relates to a PTA UUID (that is not a TA but rather an OP-TEE core build-in service), there is not no TA to load;
• if the UUID relates to a built-in "early TA", the TA image is read from core read-only segment;
• then if the UUID relates to a TA stored in the secure storage, the TA is loaded from the secure storage;
• last if the UUID relates to a signed TA store in a REE filesystem, it is loaded from there are authenticated.

OP-TEE attestation PTA is not mandated to ensure TA authentication. It is rather a runtime service to attest the state of an already loaded TA instance, to verify it is untampered (at least for its read-only segments).

(edited)

[shirinebadi]

Thanks. So if I implement my RA service as a PTA or early TA, it will get authenticated during boot by TF-A? And this establishes the chain of trust of RA?

[etienne-lms]

Yes.

[shirinebadi]

Thanks for resources and explanation.