by Javier Vicente, Samira Briongos (NEC)
Today’s System-of-System (SoS), like those in the REWIRE use cases, can form heterogeneous interconnected networks that consist of complex sub-systems and sub-networks, which are managed and maintained by various organisations. In such a scenario, establishing trust in individual devices or groups of devices is not straightforward. As the internet grows bigger and more complex, and Cloud technologies, IoT and decentralized intelligence are adopted, robust technologies must be deployed to provide assurance that remote individual devices are secure and running in a trusted state.
Isolated Execution is a trusted computing approach requiring tools and services that enable an application to be executed in complete isolation, without access from any other application on the device or the OS. One enabling technology is Trusted Execution Environments (TEE). GlobalPlatform published the first TEE specification in 2010. It was strongly based on the Arm TrustZone proposal. The TrustZone technology was proposed in 2002, but did not get widely used until 2009.
Since then, many TEE solutions have been launched to the market, like Intel’s SGX and others, but a large part of the ecosystem of TEE is still not open, and most Trusted Applications (applications running in the secure world) are controlled by the vendors and are pre-installed on devices before selling. This leaves no room for enhancement, customization or improving security, and improving security is indeed needed for all of them since vulnerabilities have been found in different commercial TEEs [1, 2, 3, 4]. Furthermore, some vendors for instance offer Arm modules that do not fully comply with TrustZone specifications, which may lead to other unknown vulnerabilities in the system. It seems only logical that complete control and personalized configuration must be in place for any IoT system that uses TEE. This is mainly why an open-source solution was chosen for REWIRE.
Figure 1. (Left) SGX security model and (right) application refactoring for an enclave (source: https://networkbuilders.intel.com/docs/networkbuilders/intel-software-guard-extensions-intel-sgx-key-management-reference-application-kmra-on-intel-xeon-processors-technology-guide-1658482773.pdf )
A customized REWIRE TEE for secure firmware updates
As introduced in [5], Keystone is the open-source TEE framework for RISC-V processors that has been selected for the REWIRE project. Keystone’s documentation is limited, as are its out-of-the-box functionalities. Keystone features – besides isolated execution of applications – very basic attestation capabilities, edge calls and data-sealing. The reason why Keystone was chosen is not its lack of documented functionalities, of course, but the sheer wealth of extended functionalities that the platform allows for, the capability for decoupling the resource management and security checks, its modular layered design and the ability of a platform provider to program the Security Monitor as needed. The vision of the Keystone designers is that the hardware should provide security primitives instead of final and closed solutions. Thus, their main goal is to support customizable TEEs so that features and security modules can be fine-tuned for each hardware platform as expressed by the requirements of a given use case.
In this sense, different new requirements have been identified for the REWIRE system, which are being fulfilled by new, customized functionalities. Some requirements the REWIRE consortium have identified cover:
- A key management system and key hierarchies.
- Attribute-based access control, through which only authenticated devices should have access to keys from the Keystone key hierarchy.
- Creation of verifiable key restriction policies, which are necessary for runtime device state integrity checks.
- Advanced cryptographic mechanisms.
- Remote attestation and local attestation using key restriction usage policies.
- Assurance of firmware authenticity, integrity and versioning, for secure firmware updates.
- Ability to update enclave applications without leaking or losing the current state of said application.
- Secure and persistent storage.
- Establishing a secure communication channel between TEEs that enables e.g. enclave migration between them.
Out of the newly defined, customized functionalities, being able to securely update firmware and software is of paramount importance in REWIRE. This new functionality shall guarantee source authentication and authorization, data protection as features that help prevent unauthorized modifications or tampering with the firmware version distributed as well as with stored data, logging, rollback/recovery process, secure storage, and restricting privileges for the update installation. In other words, the system must be able to configure – based on certain policies – the security posture of a given application, and then be able to run and securely update the application (firmware) inside an enclave, if and only if it was able to verify the integrity of such application and the applicability of the firmware update (e.g. through the version number).
The definition of new, customized elements inside the Keystone system has begun, extending the original basic three-layer scheme found in [5]. Currently, the consortium is working on the intra- and inter-component protocols that regulate the entire process flow, while a first proof of concept for this secure firmware update shall be ready in spring 2024. Stay tuned…
[1] Ben Lapid and Avishai Wool, “Cache-Attacks on the ARM TrustZone implementations of AES-256 and AES-256-GCM via GPU-based analysis”, Cryptology ePrint Archive, Paper 2018/621, 2018. https://eprint.iacr.org/2018/621
[2] Skarlatos, M. Yan, B. Gopireddy, R. Sprabery, J. Torrellas and C. W. Fletcher, “MicroScope: Enabling Microarchitectural Replay Attacks,” 2019 ACM/IEEE 46th Annual International Symposium on Computer Architecture (ISCA), Phoenix, AZ, USA, 2019, pp. 318-331
[3] Samira Briongos, Ghassan Karame, Claudio Soriente, and Annika Wilde. 2023. No Forking Way: Detecting Cloning Attacks on Intel SGX Applications. In Proceedings of the 39th Annual Computer Security Applications Conference (ACSAC ’23). Association for Computing Machinery, New York, NY, USA, 744–758. https://doi.org/10.1145/3627106.3627187
[4] Qiu, D. Wang, Y. Lyu and G. Qu, “VoltJockey: Breaking SGX by Software-Controlled Voltage-Induced Hardware Faults,” 2019 Asian Hardware Oriented Security and Trust Symposium (AsianHOST), Xi’an, China, 2019, pp. 1-6, doi: 10.1109/AsianHOST47458.2019.9006701.