RISC-V architectures are increasingly utilized in security-critical embedded systems, with OpenTitan standing out as a prominent open-source silicon Root-of-Trust. OpenTitan delivers essential functionalities, such as secure boot and execution integrity, but introduces notable area overhead. To mitigate this issue, we propose TitanSSL, a secure software stack that ofloads cryptographic operations to OpenTitan. TitanSSL comprises an OpenSSL backend, a Linux driver for system communication, and a custom OpenTitan firmware. Communication between components is facilitated through a custom Application Binary Interface (ABI), ensuring the driver remains independent of the specific cryptographic operations executed by the OpenSSL engine. This design supports extensibility, enabling the integration of additional cryptographic primitives and enhancing the system flexibility. We evaluated TitanSSL on a System-on-Chip (SoC) featuring a CVA6 application core running Linux and OpenTitan, both clocked at 40 MHz on a Xilinx VCU118 FPGA. Our results reveal that, while there is communication overhead between system components, it is outweighed by substantial performance gains. Specifically, TitanSSL achieves speedups of 40x for SHA-256 and 82x for AES-256-CBC compared to a software-only implementation running on the CVA6 core. In addition, we provide design guidelines for future optimizations to improve system performance.
The rise of open-hardware System-on-Chip (SoC) technology is reshaping various application domains,
particularly in safety-critical and security-critical Cyber-Physical Systems (CPS). These systems require
real-time responsiveness and dynamic operations to function efectively in demanding environments.
However, these attributes introduce challenges in maintaining safety and resilience against cyber threats.
To address these challenges, modern SoCs integrate specialized hardware components to strengthen
security. For example, [
The integration of OpenTitan as a Root-of-Trust ofers a secure and isolated execution environment.
However, this design comes at the cost of significant area overhead. For instance, [
Building on this motivation, our first contribution investigates the following research question: “Given an OpenTitan-based SoC, can its memory isolation and cryptographic acceleration features be utilized to provide a secure backend for OpenSSL?” Integrating OpenTitan with OpenSSL removes the need for additional external security modules and leverages OpenTitan’s private memory to securely store cryptographic keys and secrets, preventing their exposure in main memory. To achieve this integration, we develop an end-to-end software stack, comprising: i) an OpenSSL engine that interfaces with a Linux driver, ii) a Linux driver for managing secure communication between the host system and OpenTitan, and iii) a custom firmware for OpenTitan’s Security Controller (SC), a RISC-V core responsible for executing cryptographic operations.
The second contribution of this work is the implementation of the software stack with the following key functional requirements: i) full utilization of OpenTitan’s cryptographic accelerators, ii) secure management of secrets and cryptographic key generation, iii) seamless support for application-level virtual memory by the SC, and iv) communication between the application processors and the SC via a dedicated interface.
The third contribution is the validation and evaluation of our system. We characterize and analyze the performance of TitanSSL compared to software-only implementations and theoretical limits of accelerators.
Our experimental results demonstrate that, for typical cryptographic workloads, the overhead introduced by our TitanSSL software stack is outweighed by the performance gains provided by OpenTitan’s accelerators. For example, encrypting a 2048-byte payload with AES-256 in CBC mode achieves a 16.5x speed-up compared to a pure software implementation. Similarly, SHA-256 processing of a 2048-byte payload results in a 3.8x speed-up. With a payload of just 16 KiB, the speedup for SHA increases to approximately 40x, while for AES, it exceeds 80x. Under these conditions, the accelerator utilization in OpenTitan achieves 50% of its ideal performance, as calculated in the absence of memory accesses. These results validate OpenTitan’s efectiveness as a Security Controller and highlight opportunities for hardware and software optimizations in future designs.
The structure of the manuscript is described as follows. Section 3 describes the hardware architecture used for our experimental setup. Section 4 reports the software framework and the technologies used. Section 5 defines the analysis conducted on the system to establish and ensure its security measures. Section 6 explains the characterization methodology adopted to evaluate the solution, and it presents experimental results comparing the proposed software stack with the default OpenSSL implementation. Finally, Section 7 reports concluding remarks and future works.
Our work envisions a scenario where OpenTitan is integrated into the same System-on-Chip (SoC)
alongside a RISC-V application core that lacks built-in cryptographic hardware support or other
execution isolation mechanisms, as highlighted in [
In the literature, similar implementations are found in solutions like EdgeLock Secure Enclave [
The EdgeLock Secure Enclave is a proprietary security subsystem integrated into NXP processors. It employs hardware-level isolation and cryptographic protections to ensure data integrity and confidentiality while delivering robust security features. However, as a proprietary solution, EdgeLock poses significant challenges when porting or replicating its functionality for custom architectures, limiting its applicability in open and flexible SoC designs.
Keystone, on the other hand, is an open-source framework for creating secure software environments
(Enclaves) on RISC-V platforms. It achieves physical memory isolation through RISC-V Physical Memory
Protection (PMP) [
Other works in the literature propose and analyze various RISC-V architectures, focusing on their
security constraints and requirements [
Programmable Root-of-Trust (RoT) intellectual properties (IPs), such as OpenTitan, have traditionally been employed for secure boot and security services. However, their potential as Security Controllers (SC) remains largely unexplored. A key advantage of this approach is that the isolation mechanisms are independent of any specific Operating System (OS) or architectural features of the host processor. This decoupling allows OpenTitan to be integrated alongside various processors, enabling it to act as a dedicated Security Controller. With hardware cryptographic accelerators, OpenTitan can significantly improve the performance of cryptographic tasks while maintaining a high degree of security, flexibility, and portability.
As far as we know, this work represents one of the first attempts to systematically characterize the trade-ofs and microarchitectural implications of using OpenTitan as a Security Controller to support cryptographic tasks. Furthermore, we provide an OpenSSL-based evaluation demonstrating the practical benefits of this approach.
The reference platform considered in this work is shown in Figure 1. It represents a state-of-the-art
RISC-V based system, such as the one presented in [
The considered platform features three main components: i) a RV64GC Application Core, namely
CVA6, ii) a Programmable Multi-Core Accelerator, and iii) OpenTitan, the hardware Root-of-Trust.
CVA6 [
All Root-of-Trust functions are managed by Ibex [
The TitanSSL software stack is shown in Figure 2. As described in section 3, it redirects OpenSSL cryptographic tasks, such as SHA-256, RSA, and AES, required by applications running on the Application Processor to the Security Controller (the OpenTitan core). As a result, the TitanSSL software stack is divided into two parts: one that operates on the Application Processor and another that runs on the Security Controller.
The software stack within the Application Processor is essential for enabling secure communication
between untrusted environments, where applications utilize the OpenSSL library [
The TitanSSL-SCD is the final component of the software stack residing in the Application Processor. Its role is to facilitate data exchange between the TitanSSL-SCE and the TitanSSL-SCF, using a communication mailbox to transfer information in both directions. The software components operating within the Application Processor are categorized into two spaces: the User Space (depicted in green) and the Kernel Space (depicted in yellow), as shown in Figure 2.
The components running in the User Space include the two key elements of the TitanSSL-SCE. These components intercept cryptographic operations such as encryption and digital signature generation, which are triggered by user-defined applications utilizing the OpenSSL library.
The first component of the TitanSSL Security Controller Engine is the OpenSSL Engine, a library
extension mechanism defined by OpenSSL. Its purpose is to redirect the execution of cryptographic
operations to the Security Controller. This engine interfaces with the Global Platform Client API (TEEC),
a library specification designed to manage security devices [
The OpenSSL engine has two main responsibilities: i) Initializing a communication context (TEEC_Context) and a communication session (TEEC_Session) as specified by the GP Client API; and ii) Redirecting cryptographic requests (e.g., SHA-256, AES, RSA) to the lower layers of the system.
The second component of the TitanSSL Security Controller Engine is the Global Platform Client API implementation, which abstracts the underlying Security Controller to the OpenSSL Engine. This abstraction ensures the secure establishment of a communication channel with the TitanSSL-SCD, facilitating proper data exchange through TEEC_Context and TEEC_Session. It also manages the transfer of the necessary data for cryptographic operations to Kernel Space, using the TEEC_Operation structure.
Contextual information is passed to the next layer through a data structure called titanssl_parameters_t. To maintain driver agnosticism, the engine encapsulates all operation-specific information within a meta-information data structure. For instance, AES algorithms require initialization vectors (IVs) or keys, while RSA operations demand exponents and modulus values to handle asymmetric keys. Each cryptographic algorithm needing such supplementary information is represented by a dedicated data structure, such as titanssl_meta_<operation>_t.
The TitanSSL-SCD, residing in the Kernel Space, is responsible for managing requests directed to the Security Controller and enabling communication between the Application Processor and the Security Controller via the mailbox. This component exposes its functionalities through a character device, accessible to the TitanSSL-SCE. When a command is issued, the Device Driver processes the data by translating virtual addresses from User Space to physical addresses, which the Security Controller can utilize. This translation occurs in two steps: i) Pinning the memory page to prevent data corruption, and ii) Translating the virtual address to a corresponding physical address.
The TitanSSL-SCD includes a Mailbox Manager responsible for managing data exchange between the Application Processor and the Security Controller.
The Application Binary Interface (ABI) designed for sending information to the firmware consists of: i) Three Master Pages, which store the physical addresses of the input, output, and meta-information memory pages (provided by the application and engine); ii) A Header Page, which contains navigation information for the physical input, output, and meta-information pages, including the physical address of the Master Pages, the number of pages, ofsets, and page sizes; iii) Data for the mailbox, which includes the physical address of the Header Page, the requested command, session information, and the process id (pid) of the application invoking the operation.
Additionally, the mailbox triggers interrupts to the IBEX and CVA6 cores using the Doorbell and Completion registers.
The TitanSSL Security Controller Firmware (TitanSSL-SCF) is responsible for executing cryptographic operations within the secure environment provided by OpenTitan. Upon receiving a command from the Mailbox, the TitanSSL-SCF extracts the requested operation, its parameters, and the Header Page’s memory address. By accessing physical memory directly, the firmware retrieves the data structure sent by the Application Processor, which contains all the information to execute the requested cryptographic operation.
The Mailbox Manager in the Security Controller remains idle until it is signaled by the Doorbell register. Upon receiving the signal, it fetches the cryptographic task request and the physical memory address of the structure containing the operation’s inputs and parameters. The Cryptographic Accelerator Manager then processes the requested operation, which may involve tasks such as generating a hidden ephemeral key, signing or verifying a signature, computing a cryptographic hash, or encrypting a data sequence.
Once the cryptographic task is completed, the Mailbox Manager activates the Completion register, signaling the Mailbox Manager on the Application Processor to proceed with subsequent actions.
The system employs a zero-copy approach, where the firmware running on IBEX writes the output directly to memory without using an intermediate bufer or delegating tasks to the driver. Both the CVA6 application processor and IBEX access memory through the last-level cache (LLC), though CVA6 features an additional level of cache. To maintain memory consistency, the driver flushes the first-level cache before initiating the remote procedure call to IBEX. This call is blocking, ensuring that memory remains unaltered by the application during OpenTitan operations. However, in multithreaded or shared memory environments, it is the application’s responsibility to prevent concurrent access to bufers being used by OpenTitan.
The security assumptions for our system are based on the threat model outlined in the OpenTitan
analysis for SCRAMBLE-CFI [
Our analysis combines the STRIDE framework [
Our evaluation uses the STRIDE approach to assess both software components and data flows: i) Software components are analyzed for vulnerabilities related to Spoofing, Repudiation, and Elevation of Privilege. ii) Data flows are examined for risks of Tampering, Information Disclosure, and Denial of Service. It is important to note that the Application and its data flows are not included in this analysis. In this context, the OpenSSL Engine, which is rated with a criticality level of 1, operates with minimal privileges and does not store sensitive data. Since the OpenSSL Engine is accessible to all users, an analysis of Spoofing and Repudiation risks is deemed unnecessary. Moreover, Elevation of Privilege concerns are addressed by subsequent authentication layers.
In contrast, the GP Client API is assigned a criticality level of 2 due to its role as the gateway to Kernel Space on the Host Processor. This component incorporates authentication mechanisms that help mitigate Spoofing and Elevation of Privilege threats. Furthermore, the Session feature in the GP standard tracks access by processes, providing logging and monitoring capabilities to prevent Repudiation.
Within Kernel Space, the Device Driver (criticality level 5) helps mitigate threats related to Broken Access Control and Broken Authentication, thereby limiting the risk of Spoofing and Elevation of Privilege attacks. The kernel’s logging system also addresses Repudiation and Logging concerns. Both the Kernel Space’s Mailbox Drivers and the Secure Space follow a common architectural framework, although they difer in execution privileges (5 vs. 7) due to their distinct logging and monitoring capabilities.
The Secure Firmware is isolated by default and remains secure, with its primary vulnerability stemming from the potential tampering of mailbox data. Our data flow analysis specifically targets the potential leakage of sensitive information between the Device Driver and the Host Processor’s mailbox, as such a breach could jeopardize the entire system architecture. It is worth noting that other data flows are protected against vulnerabilities such as Incorrect Input Validation or Bufer Overflow, efectively preventing unauthorized access beyond bufer boundaries.
To evaluate the efectiveness of the proposed software stack, we analyze the performance of two widely used cryptographic algorithms: SHA-256 and AES-256-CBC. Specifically, we compare the runtime performance of cryptographic operations ofloaded to OpenTitan against a purely software-based implementation executed on the host core. TitanSSL was tested on a System-on-Chip (SoC) synthesized on a Xilinx Virtex UltraScale+ VCU118 FPGA (the experimental setup is shown in Figure 3), running Linux v5.10.7. The OpenTitan subsystem provides access to the JTAG interface through the FMC connector and the CVA6 processor via the PMOD slot on the board. Programming of the system is carried out using GDB in conjunction with OpenOCD, while interactions with the Linux shell are facilitated through the UART interface available on the FPGA.
The evaluation of the system was conducted directly on the Linux system running on CVA6 using the openssl speed command, specifying: i) the developed engine, ii) the payload size, and iii) the algorithm to be tested through the engine and the envelope library (EVP). For example, to evaluate the performance of SHA-256 and AES-256-CBC with a 1 KiB payload, the following commands can be used: openssl speed -engine titanssl -bytes 1024 -mr -evp sha256; openssl speed -engine titanssl -bytes 1024 -mr -evp aes-256-cbc;
The output of the first command is structured as follows: +DT:sha256:3:1024 +R:126169:sha256:3.000000 +F:22:sha256:43065685.33
This output can be interpreted as follows: • +DT:sha256:3:1024: Indicates the start of a new test session for a digest algorithm. Specifically, this test is for the SHA-256 hashing algorithm. It specifies the test duration in seconds (3 seconds in this case) and the block size (in bytes) used during the test. • +R:126169:sha256:3.000000 Represents a result record. Here, 126169 is the total number of data blocks (each of size 1024 bytes) processed during the 3-second test. • +F:22:sha256:43065685.33: Provides the calculated throughput at the end of the test. The value 22 denotes a numeric code representing a specific unit or metric (for SHA-256, it refers to throughput in bytes per second). The value 43065685.33 represents the measured throughput in bytes per second, indicating the rate at which the SHA-256 algorithm processed data during the test We also evaluate the performance of our system against the theoretical maximum throughput of the accelerators. OpenTitan features an SHA accelerator, which processes 64 bytes per 80 clock cycles when operating in SHA2-256 mode. Similarly, the AES accelerator, configured in unmasked mode, processes 16 bytes per 16 clock cycles. Given that the FPGA system operates at a clock frequency of 40 MHz, the theoretical maximum performance for the test system is 28.61 MiB/s for SHA2-256 and 38.15 MiB/s for AES-256. These values represent ideal conditions, excluding overheads such as data movement between memories or the encryption schemes applied to the algorithms.
Table 1 presents the performance results for SHA2-256 and AES-256-CBC, comparing the software implementation in OpenSSL with our TitanSSL software stack. For each test, operations were performed on varying payload sizes. To observe the efects of memory paging, payload sizes slightly smaller than multiples of 4 KiB were also tested, allowing us to capture the overhead introduced by managing additional pages.
The table columns display, for both algorithms, the operation speed in KiB/s, the speedup achieved by TitanSSL relative to OpenSSL, and the percentage of TitanSSL’s performance compared to the theoretical limits of the corresponding hardware accelerator.
In addition to providing secure in-element processing, our results show that the overhead of the TitanSSL software stack is compensated at 512 bytes for SHA2-256 and 128 bytes for AES-256. For larger payloads, TitanSSL achieves significant speedup over the pure software implementation, reaching 3.8x for SHA2-256 and 16.5x for AES-256 with 2 KiB payloads. For a payload size of 16 KiB, the speedup rises to 39.8x for SHA2-256 and 82.4x for AES-256, achieving approximately 50% of the theoretical performance of the hardware accelerators.
Figures 4 and 5 illustrate the performance trends for operations performed using OpenSSL and TitanSSL. In both figures, the left-hand graph shows the performance of the software-only implementation, which peaks at a payload size of 211, equivalent to 2 KiB, for both algorithms. The right-hand graph compares the performance of TitanSSL to the software baseline and the theoretical performance of the hardware accelerator. Both algorithms demonstrate a performance trend that increases with payload size, converging toward the ideal performance. Drops in performance are visible due to the overhead of handling additional memory pages and any padding required by the cryptographic algorithms. The gray horizontal line in the graphs highlights the point at which the overhead of the software stack is neutralized, resulting in a speedup greater than 1x. We also tested RSA with 1024-bit keys obtaining a speedup of 1.4x in signing operations and 1.0x in verification operations.
In this paper, we introduced a software stack that utilizes OpenTitan as a Security Controller (SC) within a RISC-V-based System-on-Chip (SoC). This stack enables applications operating in insecure environments to securely interact with the OpenTitan SC for cryptographic operations, as well as the generation and storage of sensitive data. To facilitate this integration, we developed a custom OpenSSL engine (TitanSSL-SCE), a communication driver (TitanSSL-SCD), and firmware for the Security Controller (TitanSSL-SCF). As a result, applications can perform cryptographic operations through the OpenSSL API, leveraging the security and acceleration features provided by OpenTitan.
To evaluate the performance of the TitanSSL-SCE and TitanSSL-SCD components, we conducted benchmarks on a Linux environment running on a System-on-Chip (SoC) equipped with a CVA6 application core and OpenTitan. The SoC was implemented entirely on an FPGA, operating at a frequency of 40 MHz. All evaluations were performed directly on the system under test using the OpenSSL speed application.
Although the TitanSSL software stack introduces some overhead, it achieved significant performance improvements; for payloads of 16KiB, we obtained speed-ups of 39.8x for SHA-WITH RESP256 and 82.4x for AES-256-CBC. For payloads of 16KiB, TitanSSL reached approximately 50% of the ideal performance achievable by the underlying accelerators. Moreover, TitanSSL consistently outperforms OpenSSL, even with smaller payloads as low as 512 bytes. These performance gains are realized while leveraging key features of OpenTitan, such as its memory isolation, secure boot, and root-of-trust capabilities.
In future work, we plan to extend TitanSSL’s evaluation by testing it with real-world network workloads, including those generated by communication protocols such as HTTPS and TLS.
During the preparation of this work, the authors used ChatGPT, Grammarly in order to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the authors reviewed and edited the content as needed and takes full responsibility for the publication’s content.