The paper defines NERVE Attacks, five orthogonal attack dimensions spanning AI-powered brain-computer interfaces (BCIs) from physical transport to trained model, and uses its EEGle framework to find 17 novel neuro-specific attacks that threaten users' mental privacy and physical safety.

problem

BCIs route neural signals through headsets, SDKs and AI models to physical devices; consumer stacks lack encryption and authentication, and AI-specific BCI attacks had never been characterised as one threat class.

key idea

Attacks on BCIs must be physiologically plausible, so attackers exploit neuro-specific properties (brain rhythms, event-locked timing, artefact-like waveforms), while generative AI supplies the neuroscience expertise non-experts lack.

how it works

Dimensions cover forged brain signals, timing shifts, replayed epochs, sniffing and spoofing of unencrypted links and sockets ('Vein Tapping'), and artefact-shaped backdoor triggers. EEGle's orchestrator runs evasion, backdoor and system engines; an LLM feedback engine chooses the next plan and synthesises new engines at runtime.

results

• 17 novel neuro-specific attacks across five dimensions, including three new attack families (neuro-mimetic forgery, temporal desynchronisation, neuro replay) and a ten-trigger backdoor suite.
• LLM-synthesised brain signals took targeted control of BrainFlow mental-state classifiers within 10 iterations, needing no data from the victim and transferring across subjects and headsets.
• A sub-second timing shift that injects no data drives EEGNet to chance; a cyclic variant preserves signal power and slips past energy-based anomaly detectors.
• BCI backdoors show a stealth–effectiveness spectrum absent from image models: high-stealth triggers leave no accuracy footprint, yet six of seven reach 99–100% success.

Read on arXiv →  ·  with G. Akkogiounoglou, L. Qendro, I. Tscherniak, A. Madhavapeddy

This systematisation of knowledge examines how Confidential Computing, using hardware Trusted Execution Environments (TEEs), has been applied to protect machine learning's confidentiality and integrity, why current protection covers only training or inference, and what research could secure the full ML pipeline.

problem

ML pipelines span mutually mistrusting parties and complex software stacks, exposing data and models to stealing, inference and poisoning attacks; yet no systematisation of TEE-assisted ML, its obstacles or long-term solutions existed.

key idea

The paper maps the ML pipeline's attack surface onto TEE capabilities, classifying protections by host location (untrusted server or client) and goal (confidentiality or integrity), and pinpoints where TEEs fall short.

how it works

It splits the ML pipeline into stages and attacks into confidentiality (data reconstruction, attribute/membership inference, model stealing) and integrity (poisoning, adversarial examples) classes, compares hardware TEEs and frameworks, and tabulates prior systems by TEE, paradigm, attacks covered and overhead, grouping solutions as whole-in-TEE, partitioned or accelerator-assisted.

results

• Every existing TEE-for-ML system protects a single stage, training or inference, so none yet secures the full pipeline from data collection to model re-use.
• Running ML inside a TEE does not by itself stop leakage: access patterns let Privado recover the class labels of encrypted inputs with 97% accuracy on MNIST.
• TEE limits shape the design space: 128MB of SGX memory and 100–1000× swapping costs push towards partitioned execution and TEE-assisted accelerators such as GPUs.

DOI →  ·  arXiv →  ·  F. Mo, Z. Tarkhani, H. Haddadi

Deluminator is a set of OS abstractions and a userspace framework that track information flows across mixed compartment types (processes, SGX enclaves, TrustZone trusted apps and intra-address-space compartments), so developers can audit policy violations and investigate attacks across these boundaries.

problem

Software now mixes process sandboxes, trusted execution environments and in-process compartments, each with its own threat model, yet OS stacks assume single-compartment processes, leaving cross-boundary vulnerabilities hard to detect.

key idea

Model each compartment as labelled system objects (threads, memory regions, files, sockets, pipes, RPCs) and trace flows between them with decentralised information flow control (DIFC) labels, reporting violations rather than enforcing them.

how it works

LibDeluminator's API (d_enable, d_add, d_malloc, plus SLABEL/ILABEL flags on open, socket and pipe) labels objects. A policy management and tracing system in the Linux kernel (29 new Linux Security Module hooks), OP-TEE and the SGX driver/SDK checks flows, including over labelled address-space regions with per-thread page tables.

results

• Follows data both locally and across the host–TEE boundary, spanning processes, SGX enclaves, TrustZone trusted apps and in-process compartments on Arm and x86-64.
• Applied to 14 sets of published SGX and TrustZone vulnerabilities (COIN, Boomerang, AsyncShock and others), it surfaced each as a policy violation with only 4–23 changed lines.
• Gives developers forensics across compartment types at an average 7–29% overhead; enclave-backed Apache httpd costs about 8% on SGX and 10.8% on TrustZone.

DOI →  ·  with A. Madhavapeddy

MicroGuards is a lightweight Linux kernel abstraction for privilege separation inside a process: each thread can wall off memory regions from untrusted code in the same thread and from other threads, at low cost on mobile and embedded Arm devices.

problem

Inside one address space, a compromised thread or unsafe library can read secrets like private keys; existing in-process isolation mostly needs specific languages or x86 features unsuited to mobile and IoT devices.

key idea

Threads become security principals holding kernel-managed labels and capabilities (after decentralised information flow control); each MicroGuard is backed by ordinary page tables or by hardware tagging such as Arm memory domains.

how it works

A Linux Security Module with four custom hooks enforces labels on MicroGuard and POSIX memory calls. Each MicroGuard has a private page table loaded on a lightweight context switch; Arm memory domains and address-space-tagged TLBs limit flushing, and the design anticipates memory-tagging (MTE) and pointer-authentication backends.

results

• Locking OpenSSL's private keys inside MicroGuards took 281 added lines and cost Apache httpd 0.47% latency (3.67% with one MicroGuard per session).
• mg_clone creates a protected thread 83.01% faster than fork, so fine-grained separation no longer requires splitting work into processes.
• One API runs over plain page tables or Arm memory domains, and is designed to adopt Arm memory tagging (MTE) and pointer authentication as backends.

DOI →  ·  with A. Madhavapeddy

The dissertation introduces dispersed compartments, isolation units whose policies span processes, enclaves and TrustZone trusted apps, and builds Sirius to enforce them on commodity Arm and x86-64 hardware, protecting data shared across these boundaries without having to trust the host kernel.

problem

Processes, sandboxes and trusted execution environments (TEEs) each have their own threat model; existing compartmentalisation cannot extend or monitor compartments beyond one privilege layer or address space, leaving cross-compartment sharing exposed.

key idea

A dispersed compartment groups threads and system objects from different address spaces under dynamic, mutually distrustful policies; dispersed monitoring checks them in each kernel and dispersed enforcement upholds them system-wide.

how it works

Chapter 3 adds three hardware-assisted abstractions: virtual address space objects (VAOs) for intra-address-space isolation, labelled cross-boundary channels and a security monitor (SSM). Chapter 4 builds Sirius: Linux and TEE-kernel monitors check information-flow labels; the SSM, in Arm Trusted Firmware, enforces them. Chapter 5 adds the userspace API and case studies.

results

• A study of 41 TrustZone and SGX applications found 92% exposed to vulnerabilities through memory, thread or IPC/RPC objects, the case for dispersed compartments.
• Sirius enforces one policy across host apps and enclaves without trusting the host kernel, anchored by a security monitor in Arm Trusted Firmware.
• Sirius's TrustZone stack runs 16% faster than OP-TEE and protects files ≈11× faster than encrypted Linux filesystems; hardening httpd took ≈400 lines.

Repository →  ·  advised by A. Madhavapeddy and J. Crowcroft

The paper analyses whole-system threats to commodity wearable brain-computer interfaces (Muse, NeuroSky, OpenBCI), where attacks can leak brainwave data or hijack BCI-controlled devices, and introduces Argus, an information flow control system that tracks and restricts sensitive dataflows.

problem

Wearable BCIs pair a head-mounted electroencephalography (EEG) sensor with a phone or Raspberry Pi running ML inference, yet use unencrypted Bluetooth, weak isolation and poor privilege management; prior work offered no defence.

key idea

Model each attack vector, system-side or adversarial-ML, as flows between labelled system objects (threads, memory regions, files, sockets, pipes), then enforce secrecy and integrity policies on them in the kernel.

how it works

A userspace library, LibArgus, lets developers label threads, files, sockets, pipes and memory regions for secrecy or integrity via new and modified syscalls; a kernel tracing and policy management system (TPMS) checks flows through hooks in the virtual file system, sockets and mmap, using ARM memory domains for tainted memory.

results

• Proof-of-concept attacks on Muse, NeuroSky and OpenBCI headsets uncovered more than 300 vulnerabilities across six attack vectors, from leaking brainwave data to seizing BCI-controlled devices.
• Exploiting BrainFlow bugs through the root-privileged OpenBCI interface gave arbitrary code execution as root; adversarial EEG inputs cut model accuracy from 70% to 0%.
• Argus, the first information-flow control system for wearable BCIs and the first to cover both system and adversarial-ML attacks, stopped all six vectors at 12–14% slowdown.

Read on arXiv →  ·  with L. Qendro, M. O'Connor Brown, O. Hill, C. Mascolo, A. Madhavapeddy

This cross-disciplinary article examines how trusted execution environments (TEEs) bear on cloud organisations' legal obligations under the EU's General Data Protection Regulation (GDPR): they can aid risk management but will not resolve compliance, and many of their benefits fall to providers.

problem

Vendors market enclaves as enabling GDPR compliance, yet how far TEEs help with legal obligations in a service-provider context, and whether they reinforce large providers' dominance, had received little consideration.

key idea

The article maps TEE properties — in-enclave protection, remote attestation, sealing — onto GDPR duties of controllers (typically tenants) and processors (typically providers), then asks who actually benefits.

how it works

It surveys the features of prominent TEEs (Figure 1), then works through GDPR's security duties (Art. 32), processor guarantees (Art. 28), encrypted personal data, analytics and machine learning, and attestation-backed data transfer, before weighing provider and tenant liabilities and market concentration.

results

• Encrypted personal data often remains personal data, so TEEs do not remove GDPR obligations; providers stay responsible even without plaintext or key access.
• Many benefits fall to providers: enclaves can show a provider was not at fault for a leak and draw risk-averse tenants to the cloud.
• It warns of a self-reinforcing cycle: TEEs become best practice, dominant providers are best placed to implement them, so consolidation and systemic risk grow.

“TEEs represent yet another security tool (one of many) that can aid risk management.”

Read on ACM Queue →  ·  DOI →  ·  J. Singh, J. Cobbe, D. L. Quoc, Z. Tarkhani

Sirius brings decentralised information flow control (DIFC) to TrustZone enclave applications, governing data flows through threads, address spaces, files, sockets and pipes in both the normal and secure worlds, so that mutually distrustful host and enclave compartments can share resources securely.

problem

TEEs have a one-way isolation model, leaving a semantic gap with the host. Analysing 41 open-source TEE applications, the paper classifies threading, memory and privilege-separation vulnerabilities that compromise sensitive data.

key idea

Treat each thread in either world as a security principal and enforce DIFC labels on kernel objects in both Linux and the TEE kernel, so enforcement is decentralised across the two kernels.

how it works

A Linux security module with 15 hooks and matching OP-TEE monitor and kernel extensions label threads, enclaves, RPCs, files, sockets and pipes. Isolated memory compartments (IMCs) give threads sharing an address space separate memory views, via per-IMC page tables or ARM memory domains; violating threads are killed.

results

• The first compartmentalisation framework to control dataflows through threads, address spaces, files, sockets and pipes in both TrustZone worlds, replacing ad-hoc host–enclave interactions.
• An analysis of 41 open-source TEE applications exposed three classes of insecure host–enclave interaction behind real CVEs, which Sirius eliminates or contains.
• Labelled file protection runs ≈81× faster than OP-TEE's secure storage, and DarkneTZ ported to Sirius outperforms the original OP-TEE version by ≈5.6%.

Read on arXiv →  ·  with A. Madhavapeddy

µTiles is a Linux kernel abstraction for privilege separation inside a process, aimed at IoT devices: threads protect memory regions from each other and from untrusted code, with protection mapped onto ARMv7-A memory domains to keep overhead low.

problem

Unix-like systems offer no privilege separation inside a process, so untrusted dependencies or a compromised thread can leak private data; Arm memory domains could help but are scarce, coarse and privileged.

key idea

A kernel virtual-memory layer hides the hardware: threads hold secrecy and integrity labels plus capabilities, and only the kernel decides which µTile occupies which of the 16 domains.

how it works

utile_mmap tags a 1MB-aligned region and assigns it a free hardware domain; when all 16 are taken, an LRU cache evicts and later restores µTiles, so they are virtualised. utile_mprotect flips the domain access register where possible, emulating read-, write- or execute-only. A four-hook Linux Security Module checks labels.

results

• Virtualises Arm's 16 hardware memory domains: when all are taken, an LRU cache evicts and restores µTiles, so a process can hold more isolated regions than the hardware has domains.
• Permission changes through utile_mprotect run 1.17× faster than mprotect for no-access and read-write, by flipping the domain access register instead of page tables.
• Isolating OpenSSL private keys from Heartbleed-style leaks took 281 lines and added 0.47% latency to Apache httpd.

Read on arXiv →  ·  with A. Madhavapeddy

Snape is an API and composable platform that lets edge applications declare which data and OS services need protecting, then maps those needs onto the device's available hardware security features rather than shielding the whole application inside one large, monolithic trusted computing base (TCB).

problem

Edge devices expose varied security hardware, yet systems such as Haven and TrustShadow shield whole applications on large monolithic TCBs, so one breach exposes everything and overheads apply even to unneeded services.

key idea

A declarative trust manifest (.stm file) names only the private data and OS services to protect, and how strongly; Snape maps each to a dedicated enclave and leaves non-sensitive calls untouched.

how it works

A Solo5-based unikernel monitor on Raspberry Pi 3 redirects protected calls to a TrustZone secure-world OS based on OP-TEE. Services run as pure in-enclave components (PIE-U in secure user mode, PIE-K as secure kernel drivers) or as trusted wrappers that encrypt and validate host filesystem and network calls.

results

• Solo5 unikernels on Raspberry Pi 3 boards use TrustZone through Snape: host OS services are swapped for hardware-assisted ones only where the manifest asks.
• Isolation becomes a per-service choice: trusted wrappers cost 2.7–4× over Linux but offer weaker security, while pure in-enclave services give stronger isolation at higher cost.
• The trusted pieces stay small (a 3k-line Snape hypervisor, 1.9K-line trusted wrappers), and porting the filesystem services to Intel SGX touched just 20 interfaces.

ACM DL →  ·  with A. Madhavapeddy, R. Mortier

The paper designs an emulation platform that lets libraries and archives give patrons remote access to restricted born-digital material: an Intel Software Guard Extensions (SGX) enclave on the patron's untrusted machine holds the keys and decrypted content, demonstrated with a modified Game Boy emulator.

problem

Libraries want to let patrons access restricted born-digital material remotely without unauthorised copying, but the patron's machine is untrusted: a compromised OS may steal keys and disk-image contents from a running emulator.

key idea

The emulator is split so only its core and a security module run in an SGX enclave; the server releases keys only after remote attestation confirms a genuine SGX platform.

how it works

A client authentication-and-verification (AV) enclave locally attests the emulator enclave, then runs remote attestation and key exchange with the institution's server. Encrypted ROMs arrive over SSHFS; the enclave decrypts them internally, re-encrypts anything cached locally and seals keys, while GUI and IO stay outside.

results

• A modified Game Boy emulator runs on the patron's own untrusted machine while ROM contents stay protected: the archive releases keys only to an attested SGX enclave.
• Encrypted content can be cached on the patron's machine, so archives avoid the latency of running emulation remotely over the internet.
• Less than 10k lines run inside enclaves, comfortably within SGX's 128MB limit, with keys sealed and local caches re-encrypted.

PDF (iPRES archive) →  ·  with G. Brown, S. Myers