Execution Layer

Acurast's execution layer is modular, allowing the flexible selection of runtimes according to the requirements of the use-case and the job, respectively. Decoupling the execution layer from the consensus and application layer allows the long-term evolution of runtimes, avoiding dependency lock-ins. Additionally, it ensures the highest level of service and confidentiality because security models can iteratively evolve with upgrades as novel threats emerge or new requirements arise.

Acurast offers native and straightforward bootstrapping of permissioned consortia. Depending on the requirements, either (a) consumers can directly leverage the Acurast orchestrator to select from a public pool of processors, or (b) or use dedicated processors (e.g., from trusted entities, or use consumer-supported self-service processors). Such composability allows consumers to customize access control and define individual trust models depending on the jobs that are executed.

The Acurast execution layer natively offers two runtimes, the (1) Acurast Secure Hardware Runtime (ASHR) and (2) Acurast Zero-Knowledge Runtime (AZKR).

Acurast Secure Hardware Runtime (ASHR)

The Acurast Secure Hardware Runtime (ASHR) is a generic approach to achieve a confidential execution layer while assuming a timely threat model, thus ensuring the highest possible level of security. The security guarantees achieved by secure hardware are generally highly divergent, from virtual processors to on-SoC processors, and finally, to the current bleeding edge of an external coprocessor, which is a physically separated and independent chip, dedicated to only security-sensitive operations [1]. The current ASHR implementation is based on coprocessors provided by the Google Titan chip [2]. The Titan chip has not been compromised, unlike most secure hardware platforms. Although high-reward bug bounties[3] and the highest zero-day vulnerability payouts[4] do not guarantee security, they are a solid indication of the security level achieved.

Rationale on using Mobile Hardware

Smartphones are among the most complex cases when it comes to information security. Their computing power has grown to the point of being almost indistinguishable from computers, they store the most valuable personal data and are used to carry out security-sensitive activities, which make them extremely attractive targets for attackers. With such a wide-ranging threat model and the fact that the vast computing base of a modern OS cannot be fully trusted, vendors have begun to use hardware to improve the security of their systems [1].

On TEEs and Hardware Security

Usually, Trusted Execution Environments (TEE) are created by integrating protection mechanisms directly into the processor or using dedicated external secure elements. However, both approaches only cover a narrow threat model, resulting in very limited security guarantees. For instance, enclaves nested in the application processor provide weak isolation and weak protection against side-channel attacks. Regardless of the approach used, TEEs often lack the ability to establish secure communication with peripherals, and most operating systems run inside TEEs do not provide state-of-the-art defense strategies, making them vulnerable to various attacks. Arguably, TEEs, such as Intel SGX [5,6] or ARM TrustZone [7], implemented on the main application processor, are insecure, particularly when considering side-channel attacks. For that reason, ASHR is based on the bleeding edge of a dedicated coprocessor.

Acurast Zero-Knowledge Runtime

The Acurast ZKP-based Runtime (AZKR) is another approach towards achieving general-purpose verifiable computation by leveraging recursive ZKP, which can generate and aggregate proofs for any computation. While the ASHR provides a performance advantage over the AZKR, the trust model of ZK-based protocols draws its core trust assumptions from the cryptographic scheme, not hardware-based security assumptions. The ASHR can scale horizontally across different applications; the AZKR requires specific circuits, assumptions, and requirements. On the other hand, ASHR provides an isolated environment for sensitive code, optimized for efficiency. Finally, trust-wise, ASHR rely on key attestation procedures and hardware-based trust assumptions, while AZKR systems mainly rely on semi-trusted sequencers and the reliance on cryptographic soundness.

References

[1] P. T. Maxime Rossi Bellom, Damiano Melotti, 2021: A Titan M Odyssey, 2021. Available on: https://i.blackhat.com/EU-21/Wednesday/EU-21-Rossi-Bellom-2021_A_Titan_M_Odyssey-wp.pdf
[2] C. Wankhede, What is the Titan M2 security chip in Google’s Pixel phones? https://www.androidauthority.com/titan-m2-google-3261547/, Jan 2023.
[3] J. Reed, Google’s bug bounty hits $12 million: What about the risks? https://securityintelligence.com/news/googles-bug-bounty-hits-12-million-what-about-the-risks-2/, May 2023.
[4] ZERODIUM, ZERODIUM Payouts for Mobiles, https://zerodium.com/program.html
[5] S. van Schaik, A. Kwong, and D. Genkin, SGAxe: How SGX Fails in Practice, 2020. Available on: https://api.semanticscholar.org/CorpusID:220248073
[6] S. van Schaik, A. Seto, T. Yurek, A. Batori, B. AlBassam, C. Garman, D. Genkin, A. Miller, E. Ronen, and Y. Yarom, SoK: SGX. Fail: How stuff get eXposed, 2022.
[7] S. Pinto and N. Santos, “Demystifying Arm TrustZone: A Comprehensive Survey,” ACM Computing Survey, Vol. 51, No. 6, Jan 2019. Available on https://doi.org/10.1145/3291047