Accessibility and Usability:
Google provides the freely available Android Security Library, which is high in quality. In addition, developers can rely on the IDE Android Studio, various SDKs, thorough documentation and example-code. Furthermore, a large community of developers exists.

Supported Features: The Android Security Library provides various mechanisms and algorithms, including many algorithms covering encryption (symmetric and asymmetric), signatures, message digest, key generation and attestation. In addition, the Android KeyStore System API supports functionality to securely store cryptographic keys. On some devices with StrongBox compatible TRH, this hardware can be used with the KeyStore API. The number of keys that can be stored by the keystore is unlimited.

Within the Trusted Execution Engine (Tensor Security Core) only the algorithms preloaded by Google can be executed. We assume that the evaluated devices use Androids own TEE implementation Trusty TEE. The TEE is used to secure the KeyStore in hardware, if StrongBox cannot be used.

Performance:
Table 4: Performance – Pixel 5, Android 12

Market share: Google Pixel devices hold a relatively low share of the smartphone market. In 2021 they held about 1,2% of the German market and about 3,8% in the US.

Accessibility and Usability: In addition to the Andorid Security Library (see section for Google Pixel), Samsung provides its own freely available security library Samsung Knox SDK. The SDK is less thoroughly documented, and the usage is less prevalent than the Android pendant, because they are Samsung exclusive and solely used to access Samsungs own TRH Samsung Knox Vault.

Supported Features: Next to the Android libraries, Samsung supports the following security functions:

• Weaver (Android password authentication),
• Credential Storage (stores keys, biometric data and more) and
• Samsung Attestation Key (supports firmware and other devices).
• The keystore Knox Vault Storage can store an arbitrary number of keys.
• The Knox Vault Processor solely executes algorithms preloaded by Samsung. We assume that the evaluated devices are equipped with Samsung’s own TEE implementation TEEGRIS, which was introduced with the Samsung Galaxy S10. TEEGRIS can be used to secure the KeyStore in hardware, if StrongBox cannot be used.

Performance:
Table 6: Performance – Samsung Galaxy A50, Android 11

Market share: In 2021 Samsung came in second in market dominance, holding about 20% of smartphone market shares.

Accessibility and Usability: Apple provides the free and high-quality Apple CryptoKit library for security features. Additionally, developers can use XCode and a large amount of documentation and code examples. The community of iOS developers is large, due to the prevalence of Apple mobile devices.

Supported Features: CryptoKit offers the SecKey API (for asymmetric keys), the Common Crypto Library (for symmetric encryption, hash-based MACs, message digest and attestation) and CryptoTokenKit (for Smart-Card support). Many ECC-256bit keys can be stored in an exclusive, secure storage unit. Different key formats are not supported. Within the Trusted Execution Engine (Secure Enclave), only the algorithms provided can be executed. Deployment of third-party code is not possible.

Performance:
Table 9: Performance – iPhone X

Market share: In 2021 Apple was the third largest manufacturer of smartphones worldwide and held a market share of 19,2%.

Accessibility and Usability:
Next to OP-TEEs open-source code TrustedFirmware also provides developers with documentation, describing the usage and the process to setup a working OP-TEE on a platform. The documentation contains a build-guide and a description of the general architecture of the OS. For more detailed information regarding the different API calls, developers have to consult the respective GP TEE API 1.0. The documentation provided by TrustedFirmware is kept reasonably up-to-date and exhaustive. In addition, TrustedFirmware provides various – unfortunately entirely uncommented – example implementations of TAs and a build.git containing an assortment of ready-to-use builds for specific platforms. To use OP-TEE on a platform not covered by the build.git, the setup process is significantly more challenging and requires some experience and knowledge with operating-system development and –architecture, since in that case the image needs to be correctly assembled using the correct elements (op-tee, linux kernel, u-boot, platform specific drivers …) creating the needed Makefiles. OP-TEE supports many different platforms, however only a few of them are represented in the build.git.

Supported Features: OP-TEE provides functions according to the GP TEE Specification 1.0 and is thus rich in features. Among others, the TEE supports RSA- and AES-encryption and provides secure storage. Currently OP-TEE does not support remote- or key-attestation. As mentioned above, the implementation of TAs is possible, and OP-TEE even enables developers to secure certain peripherals via “pseudo-TAs” using TrustZones features.
The STM board used for the experiments includes a TRNG and OP-TEE is, as far as we were able to determine, actually using it, when its random-function is called.

Perfomance:
Table 13: Performance – OP-TEE (STM32MP157A-DK1)

Market share: No information can be provided on market distribution, as no data is available. OP-TEE is, however, well-known in the community.

Accessibility and Usability:
The documentation of the NXP Plug&Trust Middleware is available for download after a cost-free registration on the NXP website. The middleware itself and its source code can be obtained in the same way (a minimal version is also available on GitHub).
The documentation is structured in a sometimes-confusing way and explanations are brief. All in all, it is, however, complete in regards of relevant information and developers with a certain knowledge of cryptography and SEs that know what they are looking for, will be able to use it without problems. The module communicates with the host via I2C and allows, in theory (we’ve only experimented with RaspberryPi 3 as host), the usage with all linux-based host devices with the respective interface.

Supported Features: The SE provides a PRNG conforming with NIST SP800-90A. Both AES- and RSA-encryption are supported, as well as different ECC-algorithms. In general, the API is quite extensive and supports many crypto primitives.
The device offers 50 kB secured user flash memory, in which Secure Objects like cryptographic keys can be stored. The implemented key store supports key-attestation. The NXP SE050 also offers a second I2C interface that can be used to connect the SE to a sensor which would allow attested sensor data reads from the host via the TRH.

Perfomance:
Table 14: Performance – NXP EdgeLock SE050 Development Kit

Market share: No information can be provided on market distribution, as no data is available. The NXP EdgeLock is part of the Google SE Alliance, which could potentially heighten its prevalence and relevance in the future.

Accessibility and Usability: The Zymbit API documentation is available on the Zymbit website in html and as PDF³. There are three distinct documentations for the C-API, the C++-API and the Python-API. The respective documents are partly inconsistent, especially regarding the descriptions of the equivalent functions in the three different APIs. One would not gain the same information about the device’s abilities and the functionalities of the methods by reading the Python-API than by reading the C-API. Even within the same language-API, different information can be gathered by reading the html version than by reading the PDF. Additionally, each documentation contains function descriptions about all methods supported by the sum of all Zymbit-devices and there is no way to filter them, in order to display only the ones relevant for e.g., the Zymkey 4i. So, for every function one must check the descriptive text, whether it is mentioned that this function is exclusive to a specific device or not. However, the reduced feature set, which will be covered in the next section, the available example code and the support of Python, the required pre-existing knowledge is relatively low and even developers that are not familiar with the C programming language, can use the API. Usage of the Zymkey 4i is theoretically possible with all devices with a I2C interface, the libraries however, are – at the time of the experiments – solely available as Debian packages and not open-source, so porting them could be difficult.

Supported Features: The Zymkey 4i offers a lock-Method, which first encrypts the input data with AES-128 and then signs it with the pre-installed ECDSA-key. It is not possible to store your own keys in the Zymkey 4i or generate new ones. A key store could only be implemented by encrypting them with the lock-function and storing them in the host memory. We assume that the Zymkey 4i uses the TRNG of the integrated ATECC608 chip, when the respective random-function is called, it was however not possible to verify this given or time and resources. Apart from the mentioned lock- and random-methods, the Zymkey supports only one more crypto-function which is ECDSA-SHA256 signatures, where only the signing is conducted on the Zymkey while the SHA digest appears to be calculated on the host device. Although the integrated ATECC608 supports more cryptographic algorithms than that, those are not used and supported by the Zymkey 4i. One would have to use the Zymbit HSM6 which is based on the same chip, in order to use these functions. Remote attestation is mentioned as a feature in the Zymkey’s Product Brief , however no information regarding how to use it could be found in the API documentation or the Zymbit forum.

Perfomance:
Table 15: Performance – Zymkey 4i

Market share: No information can be provided on market distribution, as no data is available.

Accessibility and Usability:
Different implementations of the TPM 2.0 API exist. For our experiments we used this stack implementation. To use the API one must refer to the applicable official specification documents provided by the TCG, which is quite complex and extensive. For easier use, a command line tool is provided in the above-mentioned GitHub repository. The tool itself is well documented and has examples, while the API implementation itself provides no guidance on how to use it correctly. The TPM 2.0 by Let’sTrust connects to the host device via SPI and should be usable with any Linux-based host.

Supported Features: The supported features of the Let’sTrust TPM 2.0 conform with the mandatory features specified by the TCG for the “Mobile Profile”. The TPM includes a deterministic RNG according to NIST SP800-90A. RSA and different signature algorithms are supported, as well as ECC and ECDH. However, it does not support AES encryption, or rather not the respective TPM command TPM2_EncryptDecrypt, since it is optional. Keys or other critical data can be stored in the 6kB tamper proof flash. At the time of evaluation, there was no way for remote attestation with the Let’sTrust TPM, however there are there are plans to change that. With the TPM2_Certify command, the presence of a key on the TPM can be attested, but the command TPM2_CertifyX509, which would also attest the attributes of a key/object with a X.509 certificate, is not supported by the module. The TPM does not have any other interfaces that would allow to attach further peripherals.

Perfomance:
Table 16: Performance –Let’sTrust TPM 2.0

Market share: No information can be provided on market distribution, as no data is available. However, TPM 2.0 implementations are generally widely used.

Accessibility and Usability:
The Kinibi-M SDK is not open-source and can only be obtained (for free) after registration and request on the Trustonic website. Currently the only supported chip is the Atmel SAML11 (the production SDK is restricted to the SAML11 KPH, that includes the pre-installed unique device key). The SDK includes extensive, well-structured documentation of the API, a step-by-step Getting Started guide and several, well-documented code examples that make the SDK accessible.

Supported Features: The Kinibi-M Crypto API offers, among others, the following relevant functionalities: AES-128 encryption, SHA256 hashing, secure data storage in the Secure Storage (1kB on-board data flash) and random number generation. The latter could either be obtaining numbers from the TRNG of the SAML11 or a DRNG implementation. The documentation does not give any information regarding this.
Key- or remote-attestation, in the sense that those terms are usually used in, is not implemented. Using the features of TrustZone-M, peripherals can be secured and accessed by the TAs. The SDKs intention is to enable developers to create TAs for Kinibi-M, so third party code can be executed.

Perfomance: Since time measurement on SAML11 Xplained Pro would have been incomparably more complex - as well as fundamentally different - than with the Linux-capable other boards, no performance measurements could be carried out on this board in the short time available.

Market share: No information can be provided on market distribution, as no data is available. Kinibi-M is currently only available on a single platform and hence the market share is supposedly very low. If more devices based on ARM Cortex-M CPUs with TrustZone-M support emerge, the prevalence of Kinibi-M may increase, due to the former popularity of Kinibi in the mobile sector.