1

There are different scenarios when it's about secure computation/storage on mobile devices, e.g., "REE only", "REE + TEE", or "REE + SE" or "REE + TEE + SE".

REE - Real Execution Environment, i.e. default OS (e.g., Android)
TEE - Trusted Execution Environment: secure area of CPU, isolated from REE
SE - Secure Element: standalone chip, isolated from REE

"Classical" REE app resides in phone memory, and all the operations are done within the REE environment - this is obvious. However, I wanted to clarify how the processes are distributed across the components (REE/TEE/SE) in the above-mentioned "multi-component" scenarios:

  1. Do I understand right, that there always is the "REE part" of the app, which the user interacts with (e.g., digital wallet), but when TEE is added to the solution is the "TEE part" of the app is added too? It resides on TEE, performs secure computations and TEE also serves as a container to securely store data, right? So REE part of the app plays a role of the UI "frontend", while TEE part is kind of "secure backend" - does it work that way?
  2. When both TEE and SE are part of the solution - which of them serves (or at least is recommended) to perform computations and which - to act as a secure data storage? Does an additional "SE part" of the app appear in this scenario, or does it rather depend on the role of SE (e.g., app is needed for computations, but is not needed if SE serves as a storage only)?
  3. Am I right that it's only REE or TEE that can connect developer to device hardware (e.g., biometric sensor, camera, etc.), i.e. SE does not have this functionality?
Shakalakah
  • 13
  • 2

1 Answers1

1

TEE does not have its own storage unit to store dynamic data. Chipmakers provision TEE with an embedded immutable storage that stores private keys of TEE and it is not accessible by the OS. See,

Does the ARM TrustZone technology support sealing a private key under a code hash?

Secure keys in hardware

Extra features required for TrustZone to provide main security features

There are 2 secure environments available in android:

  1. TEEs are referred to as Hardware-backed Keystore.

  2. In modern android flasgships you will see discrete Secure Element like Titan M chip in Google Pixel and Samsung Knox in Samsung premium phones. These are referred to as strongbox keystore.

Whatever be the underlying keystore used, it does not change the functional execution of apps but the OS does let the apps know that which keystore is available and accordingly the apps can choose to enable and disable some of their features based on what is available. E.g. DRM provisioned apps like Netflix decreases max resolution if the device is not equipped with EAL4+ TEE or SE. Netflix web service can even refuse service to the client app if the device is not running qualified keystore.

To use secure environment in android, apps use Android Keystore System that provides access to the features of hardware-backed keystore or of strongbox. If both are available, the app can decide for itself but the default priority is given to strongbox.

The order of priority in terms of what android keystore system considers most secure is as follows:

Secure Element (Strongbox) > TEE (hardware-backed keystore) > software-backed keystore (Deprecated)

Digital Wallets and Digital Car keys can use both of them.

Biometric sensor can have its own secure element to store the biometric data and it talks to the hardware keystore using SPI channel to communicate the authentication result and to enroll new biometric authentication. eSIMs are always discrete Secure Elements with one active SIM profile per eSIM.

defalt
  • 6,451
  • 2
  • 24
  • 38
  • Thank you so much! Smth. is still not clear, may I ask you to clarify it please? You say _"OS does let the apps know that which keystore is available and accordingly the apps can choose to enable and disable some of their features based on what is available"_ . I know that on the production stage SE can be loaded with secure applications selected by the device manufacturer. Does that mean that the end-solution app may have **both** - a UI part in REE and secure backend in SE (or TEE)? Like the Netflix app - it doesn't use SE as a storage only, i.e. there's an **app** in SE area, right? – Shakalakah Oct 02 '22 at 08:36
  • No, apps are generic. None of their components can be installed as trusted apps in keystore. They run like regular user apps within the android framework. They are only allowed to use features of keystore to protect their cryptographic assets. No exception for Netflix app either. – defalt Oct 02 '22 at 16:12
  • In my assumptions I'm based on what Thales (one of the leading SE manufacturers and Google's partner) says about apps residing on SE [here](https://bit.ly/3ydgDiO) and [here](https://bit.ly/3Swroox). They even have a [Hub](https://bit.ly/3C31Xnl) which helps such app owners to manage them, e.g. perform remote security upgrades. Will be great to know your opinion on whether I understood Thales correctly in that part of the app (as a piece of functional code) can reside in SE and "talk" to another part which is resided in REE (as actually 99.9% of apps are). – Shakalakah Oct 03 '22 at 10:22
  • This is possible to achieve but not at user's end. The app owner has to make agreement with the OEM to install a component of their app as a trusted app (TA) inside the keystore or deliver it to the keystore by OTA updates. In fact this is how Google Widevine DRM works. App developers including Netflix app, they just use Widevine API which is installed as TA by every OEM. But of course these API calls are not direct and require a system app like Google Play Services that talks to android keystore API that talks to HAL that talks with Widevine TA. – defalt Oct 03 '22 at 11:59
  • Thank you for the Google DRM info - will dive deeper in that! So finally I was right assuming that the app may reside partially in REE partially in TEE/SE, i.e. these secure environments can serve as much more, than just a key storage, and can perform "business logic" operations. May I ask the last one please? Is it true, that to access SE "basic" functionality one can use _either_ Android Keystore API _or_ Android StrongBox (i.e. both provide app developers with more or less equal functionality), however to utilize "advanced" SE logic one must use Open Mobile API (OMAPI)? – Shakalakah Oct 04 '22 at 08:16
  • No. Android Keystore API is a generic API of android that communicates with the hardware keystore. Any vendor specific advanced functionality of the chip must be accessible with android keystore API. – defalt Oct 04 '22 at 09:05