Security of Trusty OS (TEE) Non-Secure World API

Question

Recently I learned about TEE in Android, Trusty OS and its internals. I read through the articles on source.android.com and there is one thing I did not find there.

Trusty OS has its own API which allows TEE applications to expose ports and communicate with each other. It is also possible to use the TEE API to communicate between the Secure World and the Non-Secure World if the trusted application allows it during creation of the port.

My question is: How can the trusted application make sure that only selected applications from the Non-Secure World can access the port?

The accept method in Trusty Server API has the UUID of the client application as a parameter, but the documentation states that in case the communication comes from the Non-Secure World, the UUID is set to 0.

Is there even a way how a trusted application can securely determine which application from the Non-Secure World connected to it?

My idea of an attack scenario was that an Android device is compromised (rooted by an attacker) which means that the attacker can add a system daemon. The daemon uses the Trusty API to communicate with trusted applications and de-facto compromises the TEE even though the attacker does not have a direct access to it - e.g., the attacker's daemon can request encryption/decryption/signing of arbitrary data using the keys stored by the Keymaster TEE application.

Is there any protection against that?

Answer 1

How can the trusted application make sure that only selected applications from the Non-Secure World can access the port?

Is there even a way how a trusted application can securely determine which application from the Non-Secure World connected to it?

I've fielded these questions more times than I can count in reference to TrustZone apps in general. So I will speak broadly and this applies to TrustyOS or any other TEE I'm aware of. No, there is no way at present to authenticate a normal world app in a convincing way. Anything a user/app knows/is/has in normal world, a sufficiently advanced attacker can forge.

One can restrict access via SELinux policy or Linux filesystem access and this in a way "authenticates" the caller (as having access). But this falls apart again in the face of a sufficiently sophisticated attacker.

In the best case a TrustZone app is not useful to an attacker (ie unilaterally takes action based on an input the attacker cannot forge). In the case of HSM-like TrustZone Apps, the best that can be presently said about them is they hide the key material. But they, like any other HSM, will gladly encrypt/sign anything for anybody with the right access/credentials.