├── README.md ├── sancus-v-overview.png └── vrased-overview.png /README.md: -------------------------------------------------------------------------------- 1 | # Mind the Gap: Studying the Insecurity of Provably Secure Embedded Trusted Execution Architectures 2 | 3 | This repository is the hub for the code accompanying our [paper](https://mici.hu/papers/bognar22gap.pdf) "Mind the 4 | Gap: Studying the Insecurity of Provably Secure Embedded Trusted Execution 5 | Architectures" to appear at the IEEE Symposium on Security and Privacy 2022. 6 | 7 | > M. Bognar, J. Van Bulck, and F. Piessens, "Mind the Gap: Studying the Insecurity of Provably Secure Embedded Trusted Execution Architectures," in 2022 IEEE Symposium on Security and Privacy (S&P). 8 | 9 | As our case study includes several provably secure embedded security 10 | architectures, the accompanying source code is logically split across several 11 | repositories, linked below. 12 | Specifically, for every security architecture we studied, we forked the 13 | original open-source project in a separate repository, which allows to 14 | implement our proof-of-concept attacks on top of the original commit history. 15 | 16 | **:heavy_check_mark: Continuous integration.** 17 | We added continuous integration for every project to provide a 18 | fully reproducible build environment and reference output for all our attack 19 | experiments, executed via a cycle-accurate 20 | [`iverilog`](http://iverilog.icarus.com/) simulation of the systems' respective 21 | [openMSP430](https://github.com/olgirard/openmsp430/)-based designs. 22 | 23 | **:no_entry_sign: Mitigations.** 24 | Finally, when applicable, we provide simple patches for the identified 25 | implementation flaws in a separate mitigations branch of the respective project. 26 | Note, however, that these patches merely fix the identified vulnerabilities in 27 | the respective reference implementations in an _ad-hoc_ manner. 28 | Specifically, our patches do not address the root cause for these oversights 29 | (i.e., in terms of preventing implementation-model mismatches, missing attacker 30 | capabilities, deductive errors) and cannot in any other way guarantee the 31 | absence of further vulnerabilities. 32 | We provide more discussion on mitigations and guidelines in the paper. 33 | 34 | ## Sancus_V: Provably secure interruptible enclaves [![CI](https://github.com/martonbognar/sancus-core-gap/actions/workflows/ci.yaml/badge.svg)](https://github.com/martonbognar/sancus-core-gap/actions/workflows/ci.yaml) 35 | 36 | Our attack source code, continuous integration, and reference output are 37 | provided in a separate 38 | [sancus-core-gap](https://github.com/martonbognar/sancus-core-gap) repository. 39 | 40 | ![sancus-v-overview](sancus-v-overview.png) 41 | 42 | The original Sancus_V provably secure interruptible enclave processor is 43 | described in the following [paper](https://jovanbulck.github.io/files/csf20-irq.pdf). 44 | 45 | > M. Busi, J. Noorman, J. Van Bulck, L. Galletta, P. Degano, J. T. Mühlberg and F. Piessens, "Provably secure isolation for interruptible 46 | enclaved execution on small microprocessors," in 33rd IEEE Computer Security Foundations Symposium (CSF), Jun. 2020, pp. 262–276. 47 | 48 | ## VRASED: Verifiable remote attestation [![CI](https://github.com/martonbognar/vrased-gap/actions/workflows/ci.yaml/badge.svg)](https://github.com/martonbognar/vrased-gap/actions/workflows/ci.yaml) 49 | 50 | Our attack source code, continuous integration, and reference output are 51 | provided in a separate 52 | [vrased-gap](https://github.com/martonbognar/vrased-gap) repository. 53 | Furthermore, the [apex-gap](https://github.com/martonbognar/apex-gap) 54 | repository contains the attack on the VRASED secure peripheral extension in the 55 | derived APEX security architecture. 56 | 57 | ![vrased-overview](vrased-overview.png) 58 | 59 | The original VRASED verifiable remote attestation hardware-software co-design, 60 | is described in the following [paper](https://www.usenix.org/system/files/sec19-nunes.pdf). 61 | 62 | > I. D. O. Nunes, K. Eldefrawy, N. Rattanavipanon, M. Steiner, and G. Tsudik, "VRASED: A verified hardware/software co-design for remote attestation," in 28th USENIX Security Symposium, 2019, pp. 1429–1446. 63 | 64 | **:warning: VRASED derivatives.** 65 | Multiple derived architectures have been published that are 66 | directly derived from the open-source VRASED research prototype and 67 | use its security arguments as the basis of their own. 68 | At the time of writing, open-source VRASED-based security architectures include 69 | [RATA (CCS'21)](https://github.com/sprout-uci/RATA), 70 | [APEX (USENIX'20)](https://github.com/sprout-uci/APEX), and 71 | [PURE (ICCAD'19)](https://github.com/sprout-uci/vrased/tree/pure). 72 | While we only validated the attacks in this repository on the original VRASED 73 | base architecture, they may similarly affect these derived architectures. 74 | 75 | ## Paper abstract 76 | 77 | The security claims of a system can be supported or refuted by different kinds 78 | of evidence. 79 | On the one hand, *attack research* uses empirical, experimental, inductive 80 | methods to refute security claims. If motivated and competent 81 | attackers do not succeed in breaking a specific security property, this 82 | provides some support (but no definite proof) that the system is secure. 83 | 84 | On the other hand, *formal methods* use mathematical, deductive methods 85 | that can prove the security of a *model* of the system. The process of 86 | constructing a proof can uncover vulnerabilities that can then be 87 | fixed. The use of formal methods can be very powerful and is attractive 88 | because it seems to provide irrefutable evidence of security. However, that 89 | evidence applies only to the mathematical model, not to any actual system, and, 90 | hence, it is important to understand the gap between the model and the 91 | real-world system. 92 | 93 | In this paper, we present a case study that examines this gap for two 94 | embedded security architectures that use formal methods to prove their 95 | security properties. Despite strong formal evidence for security, we discover 96 | numerous attacks against the implementations, all of which falsify proven 97 | security properties. These attacks range from exploiting simple programming 98 | errors to a novel DMA-based side-channel attack. 99 | The simple attacks demonstrate that the construction of systems and proofs is 100 | error-prone, while some of the more sophisticated attacks serve as examples to 101 | show that formal methods alone can never guarantee the security of a 102 | real-world system. 103 | 104 | From our case study, we also distill actionable guidelines on how to 105 | provide stronger evidence for the security of a system. 106 | -------------------------------------------------------------------------------- /sancus-v-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/martonbognar/gap-attacks/8027cfc616d0c7cd86881a370f13d39e845b6b4a/sancus-v-overview.png -------------------------------------------------------------------------------- /vrased-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/martonbognar/gap-attacks/8027cfc616d0c7cd86881a370f13d39e845b6b4a/vrased-overview.png --------------------------------------------------------------------------------