In an Arm TrustZone based Trusted Application (TA), how can a remote party tie an output to a particular TA?

Question

I've been looking at the following figure which shows, with Arm TrustZone architecture, resources of a system can be divided into a Rich Execution Environment (REE) and a Trusted Execution Environment (TEE).

Here I'm trying to understand the following: Suppose a remote party wants a particular trusted application (TA) running in TEE to do some computation on his input. How can this remote party be ensured that the computation is actually done by the correct TA ?

Answer 1

Have the TA's output include a signature of the result of the computation, made with a key that only the TA knows.

The signed data needs to include the parameters of the computation as well, not just the result. Otherwise an adversary could take results of one computation and pretend they were the result of a different computation that the TA has also performed. If it's more convenient, you can use a cryptographic hash of the parameters instead of the parameters themselves.

Include the TA version as well, so that if there's a bug in a version of the TA you can decide to reject its computations. (This doesn't help if the TA has a vulnerability that allows the attacker to modify the version in the signed data. If this happens, you either need to rotate the signature key, or rely instead of the TA version in the TEE's attestation as described below.)

The next question is, given a signature, how do you know that it's genuine? You need a public key infrastructure to tie TA's public keys with their identity. The root of trust for the computation includes:

• The TEE manufacturer. A TEE consists of hardware and software, often made by different entities, but for your purposes you can consider the TEE manufacturer to be a single entity.
• The TA manufacturer.
• The entity or entities involved in installing the TA onto the TEE. In this answer, I'll call these entities collectively “the TSM” (trusted service manager).

TEEs usually offer an “attestation” functionality. Exactly what goes into an attestation varies, but the general idea is that an attestation is a signature over some data which includes both identifying information for the TA and identification information for the TEE it's running on. The signature is by a key which has a trust path to a certification authority (CA) run by the attestation authority. The attestation authority is usually the TEE vendor or the TSM. The attestation says something like:

TA {1234-567-89a} version 4.2 running on Yoyodyne TEE operating system 1.1.7 running on an ACME-TZ-5522 chip, on 2020-06-25 at 22:16:44, said:

Moo

Signed, the TEE.
Signed the public key of the TEE, the TSM operating CA.
Signed the TSM operating CA, the TSM root CA.

Depending on how your TEE/TSM infrastructure is set up and the circumstances under which you perform the computation, it may be more convenient to have the TA emit an attestation for each computation result, or to have a TA generate a private key when it's installed, attest the public key once and for all, and use its own private key to sign each computation result.