Forking QEMU to emulate and secure the Tillitis TKey
summary
A working QEMU-based emulator is forked QEMU to run the RISC‑V RV32 device model, attach GDB, load real device bins and exercise firmware and client apps; this workflow finds a time-of-check time-of-use leak in the signer that allows leaking one unknown byte of a signed message and recovering it by ED25519 brute-force of one byte against the public key. Fixes include refusing oversized lengths, restructuring stack data to guarantee layout, and a hardware fix to stop RAM wrap; hardware ships since Mar 2023 and the emulator accelerates development but must be validated on real devices.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:16Tillitis TKey overview
- 3:03TKey dynamic design
- 6:16Measured boot & identity
- 9:09Device identity computation
- 10:35Hardware & tooling
- 11:37Open-source ecosystem
- 13:45Software stack & languages
- 15:33Why an emulator is essential for TKey development
- 17:19QEMU bridging gaps
- 19:05Firmware testing with QEMU
- 20:30QEMU fork challenges
- 23:03Debugging limitations
- 24:28Vulnerability analysis
- 27:21Memory leak root cause
- 31:59Hardware addressing flaw
- 32:40Future of QEMU emulator
- 33:46Next-gen TKey features
- 34:28TKey capabilities summary
- 35:11Q&A
related talks
41mQEMU: Emulating Your Way to Success
34mRISC-V-Based Sandboxing for Secure and Efficient Software Execution
21mTEEP (Trusted Execution Environment Provisioning) on RISC-V
36mExploiting Buffer Overflows on RISC-V
22mHunting and Exploiting Recursive MMIO Flaws in QEMU KVM
32mDeveloping the RISC-V Hypervisor Extensions in QEMU
32mClosing Keynote: The Joy and Excitement of Forbidden Computer
31mBypassing Anti-Debugging: A Hybrid Real-Simulated Approach to Rootkit Analysis