By NEC and RUB
Samira Briongos from NEC and Annika Wilde from Ruhr University Bochum presented the implementation of secure software updates on trusted applications in RISC-V systems. The presentation began with an overview of Instruction Set Architectures (ISAs) and RISC-V, as an open-source ISA designed by Berkeley, emphasizing its modularity and the growth potential among the members of the global cybersecurity community. RISC-V’s open nature allows for more community contributions and the capabilities to detect and patch security threats.
Within the context of Trusted Execution Environments (TEEs), as isolated and secure areas, as part of a processor which protects both the code and available data during runtime from unauthorized access, including the operating system and hypervisor. In such an environment, the importance of a root of trust and the use of attestation to verify that code is running within the TEE before secrets are assigned, while various proprietary and standard API solutions exist for building TEEs, RISC-V utilizes Keystone.
In the context of REWIRE Approach and Architectural Framework, Keystone is an open-source security monitor layer for RISC-V that operates at the highest privilege level (machine mode), providing isolation for enclaves through physical memory protection. To this end, REWIRE enhances Keystone by leveraging RISC-V features without requiring hardware modifications, making it compatible with any RISC-V-compliant processor. Ay the same time, REWIRE manages to add functionalities to the security monitor, such as data sharing, key management, enhanced attestation, execution tracing, enclave migration, and secure enclave updates.
Moreover, in the context of device lifecycle management, several secure update protocol challenges are realized. The need for secure software updates is fundamental, with commercial TEEs having limitations regarding state migration between enclaves with different developer keys. As a result, designing a secure update protocol for enclave software, particularly in order to address the need for prevention of rollback attacks to potentially insecure previous versions, is considered quite a challenging task. The necessity of state synchronization between old and updated enclaves to ensure that the new version reflects state changes made after the transfer. Finally, there is the need for strong evidence confirming the correct installation of the update.
To this end, the REWIRE Approach on the Update Protocol involves four main steps for secure enclave software updates. These steps include (a) the update trigger, (b) update package generation, (c) update verification on the target device, and (d) the final execution of the updated enclave. More specifically, updates can be triggered by threat identification through risk assessment or by the introduction of new software versions. In both cases, the developer creates an update package containing the updated software, a consistent software ID, an increasing software version number, and a developer signature, publishing it to the blockchain.
Following this, there are two types of updates, One-to-One and One-to-Many. In the case of one-to-one for a specific device, where the update package can be optionally encrypted with the device’s software update key, and in the case of one-to-many for multiple devices, encryption is not feasible due to device-specific keys. The update verification process, where the target device’s update service fetches the package, initializes a host for the updated enclave, and queries the security monitor. The security monitor verifies the signature, software identity, and version number, ensuring it’s higher than the current version to prevent rollback attacks. Finally, as far as the enclave attestation and state transfer is concerned, after the successful verification, the updated enclave is attested using the REWIRE enhanced CVA testation scheme, generating a report encrypted by the side-channel resistant enclave using the software update key/ The security monitor then runs the updated enclave, triggering the old one to provide a state snapshot before being isolated.
After the complete overview and presentation of the key developments, a simplified demo application was presented analytically to showcase the update process flow. Beginning with a four-letter input from the user and storing it in the enclave state, outputting the entire state upon each input for visualization. The demo execution steps were demonstrated beginning with the original application, its verification and decompression, and the initialization with software ID and version. During the demo, the check update wrapper function was also showcased, and the enclave awaited the user’s input for processing it.
The attestation of the original enclave and the starting of the updated binary, which undergoes similar verification and parameter setting before holding for a signal to proceed with the update. Helper functions were used to attest the updated enclave and signal it to proceed. The updated enclave signals the old one about the pending update, the old enclave derives a ceiling key, encrypts its state, and writes it to a file. The updated enclave then reads and decrypts the state, imports it, after which the old enclave is isolated and the new one becomes active, retaining the previous state and accepting the new input.