-
-
Notifications
You must be signed in to change notification settings - Fork 24
Home
Welcome to the betrusted-soc wiki!
betrusted.io aims to extend the boundary of security enclaves to include user I/O. Rather than just securing private keys and computing cryptographic operations on said key, betrusted.io aims to explore the minimum viable set of human computer interactions that can be securely implemented within the boundaries of a monolithic enclave.
Thus, in the context of a minimalistic computational environment of a self-contained security enclave, the big questions are:
- How do we implement multi-lingual IMEs and unicode font rendering? In other words, how do we accommodate the linguistic diversity of a global userbase?
- How do we implement the secure rendering of bitmap images? In other words, what's the trade-off between a sufficiently simple image format with a small attack surface and a sufficiently rich image format for interoperability?
- How to implement a secure chat? In other words, how do we get Signal to fit inside a secure enclave?
- How to implement a peer to peer secure voice call and/or audio snippets in chat?
Don't see your favorite use case on the list? See HCI target rationale.
Many of these questions have obvious or popular answers in the context of a fully featured mobile SoC (several GHz CPU, several GiB RAM). However, a self-contained cryptographic enclave is estimated to have a CPU that runs around a couple hundred MHz, with a few megabytes of RAM, and perhaps dozens of megabytes of storage (based on e.g. fabricating an enclave in a 40nm silicon process with a wirebonded in-package SPI ROM). See hardware systems architecture analysis for more details on these constraints.
Furthermore, simply pulling in existing open source frameworks for many of these applications introduces security surfaces that may be too difficult to harden, so some libraries need to be re-coded for the specific context of a security enclave.
In order to answer the HCI (Human Computer Interaction) questions, betrusted.io aims to develop a hardware almost "looks like works like" prototype of an enclave + I/O so that developers have a corporeal target to work against.
The initial prototype is explicitly not evil-maid attack resistant, but should offer hermetic remote-exploit resistance at the software level even against APTs.
Once the code base and HCI scenario is validated, the requirements of an ASIC to support the task will be clear. This allows the second phase of creating a hardware enclave in silicon to proceed. Given that Moore's Law has slowed down, it's likely a 40nm (or 28nm if we can afford it) enclave will continue to be relevant for quite some time, and there should be a reasonable ROI around raising the necessary funds to tape out such a chip.
The device itself should be hardened against evil maid attacks by a well-prepared adversary with temporary access to the hardware, but may not be hardened against an adversary with unlimited physical access to the device. In other words, should an attacker have access to a device for several hours in a well-equipped lab, but the device needs to be returned to the owner in a functional state (but perhaps with significant evidence of tampering), no secrets should be divulged as a result of said analysis. In other words, with high likelihood any successful attempt to recover secrets from a device with direct physical access should leave the device in a state where naked-eye visual inspection can detect evidence of tampering.
However, should an attacker have unlimited access to the device and can perform destructive measurements on the device, secrets may be divulged (such as attacks that require direct access to the silicon die). However, in this scenario the device owner should at least be aware of the compromise once the device is returned.
The RTL of the ASIC will be open for inspection, but due to the secrecy restrictions imposed by ASIC vendors the entire chip will not be inspectable as a mask-level blueprint (besides, there is a TOCTOU on the mask design -- no guarantee that the mask design submitted for inspection matches the mask design that was actually printed by the fab). Instead, the RTL shall be hardened against potential "hard-IP" exploits with hardware ASLR. See ASIC hardening for more details.
Let's keep notes and ideas about betrusted.io here.
Untriaged ideas can be kept in the ParkingLot
How we got here: hardware systems architecture analysis
Making noise: avalanche noise source notes