Open Source Is Insufficient to Solve Trust Problems in Hardware [video]
source link: https://media.ccc.de/v/36c3-10690-open_source_is_insufficient_to_solve_trust_problems_in_hardware
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
While open source is necessary for trustable hardware, it is far from sufficient. This is because “hashing” hardware – verifying its construction down to the transistor level – is typically a destructive process, so trust in hardware is a massive time-of-check/time-of-use (TOCTOU) problem. This talk helps us understand the nature of the TOCTOU problem by providing a brief overview of the supply chain security problem and various classes of hardware implants. We then shift gears to talk about ways to potentially close the TOCTOU gap, concluding with a curated set of verifiable components that we are sharing as an open source mobile communications platform – a kind of combination hardware and software distribution – that we hope can be useful for developing and deploying all manner of open platforms that require a higher level of trust and security.
The inconvenient truth is that open source hardware is precisely as trustworthy as closed source hardware. The availability of design source only enables us to agree that the designer’s intent can be trusted and is likely correct, but there is no essential link between the hardware design source and the piece of hardware on your desk. Thus while open source is necessary for trustable hardware, it is far from sufficient. This is quite opposite from the case of open source software thanks to projects like Reproducible Builds, where binaries can be loaded in-memory and cryptographically verified and independently reproduced to ensure a match to the complete and corresponding source of a particular build prior to execution, thus establishing a robust link between the executable and the source.
Unfortunately, “hashing” hardware – verifying its construction down to the transistor level – is typically a destructive process, so trust in hardware is a massive time-of-check/time-of-use (TOCTOU) problem. Even if you thoroughly inspect the design source, the factory could modify the design. Even if you audit the factory, the courier delivering the hardware to your desk could insert an implant. Even if you carried the hardware from the factory to your desk, an “evil maid” could modify your machine. This creates an existential crisis for trust – how can we know our secrets are safe if the very hardware we use to compute them could be readily tainted?
This talk addresses the elephant in the room by helping us understand the nature of the TOCTOU problem by providing a brief overview of the supply chain security problem and various classes of hardware implants. We then shift gears to talk about ways to potentially close the TOCTOU gap. When thinking about hardening a system against supply chain attacks, every component – from the CPU to the keyboard to the LCD – must be considered in order to defend against implanted screen grabbers and key loggers. At every level, a trade-off exists between complexity and the feasibility of non-destructive end-user verification with minimal tooling: a system simple enough to be readily verified will not have the equivalent compute power or features of a smartphone.
However, we believe that a verifiable system should have adequate performance for a select range of tasks that include text chats, cryptocurrency wallets, and voice calls. Certain high-risk individuals such as politicians, journalists, executives, whistleblowers, and activists may be willing to use a device that forgoes bells and whistles in exchange for privacy and security. With this in mind, the Betrusted project brings together a curated set of verifiable components as an open source mobile communications platform - a combination open source hardware and software distribution. We are sharing Betrusted with the community in the hopes that others may adopt it as a reference design for developing and deploying all manner of open platforms that require a higher level of trust and security.
Download
Recommend
-
23
Note: This post is based on the lightning talk I gave at Devcon 5 on the same topic. The slides for that talk can be downloaded fromhere.
-
18
Security advisory 2020-03-03 – insufficient data validation in yubikey-val Tracking ID: YSA-2020-01, CVE...
-
16
vCLS VMs not powering on, insufficient resources error Duncan Epping · Nov 26, 2020 ·
-
15
Contributor jhjourdan commented
-
7
What is the fastest way to create an insufficient memory state in C? advertisements I am writing unit tests for a library I am developing. The...
-
10
& ldquo; Insufficient memory & rdquo; when running the query in Delphi 7 using BDE Paradox 7 advertisements When I run the program whi...
-
9
Don’t miss what’s happeningPeople on Twitter are the first to know.
-
22
CVE-2021-36260 CVE-2021-36260 POC command injection vulnerability in the web server of some Hikvision product. Due to the insufficient input validation, attacker can exploit the vulnerability to launch a command injection attack by s...
-
7
Fourth Pfizer Dose Is Insufficient to Ward Off Omicron, Israeli Trial Suggests Re:
-
6
Why does Haskell's take function accept insufficient elements? Why does Haskell's take function accept insufficient elements? This post is a long-form response to a
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK