Excellent work. I completely agree that today the easiest option to develop safe hardware is using FPGAs.<p>Two things to look forward:<p><pre><code> 1. Usage of open source FPGA synthesis and implementation tools
2. Usage of open source FPGA chips :)
</code></pre>
I've already seen some traction happening for open source FPGA tools, but open source FPGA chips are only in my head (as far as I know).<p>I'm a chip designer myself, and for years I have been thinking on kickstarting something to pay for a tapeout of an open source FPGA. If anyone is interested let me know, I live in Ontario/Canada.
> open hardware is precisely as trustworthy as closed hardware. Which is to say, I have no inherent reason to trust either at all<p>I think the sentence should be rewritten as "closed hardware is precisely untrustworthy as open hardware", meaning that open reveals limits and assumptions while close is pretending there are none and everything is secure, while it's precisely not.<p>The trust imo is not in the product, is in the company or team building the product.<p>> I’m a strong proponent of open hardware, because sharing knowledge is sharing power.<p>This is what, I think, makes a company or team more trustworthy. Not just making a product (even if it's really great and has the ambition to protect millions) but also sharing knowledge with the ambition that more can learn.
One idea on how to verify equivalence between a design and a physical chip:<p>If we have the design, could we generate instruction sequences (or, in general, input sequences) and deterministically predict the time required and power consumed to execute those instruction sequences? Then we could fuzz the chip with a bunch of generated code and measure that the consumed time and power matches what we expect. Any backdoor would throw off the measurements.<p>Can anyone who knows hardware better comment on whether there are other kinds of attacks that this wouldn't cover?<p>This idea is inspired by a paper I read once which used a somewhat similar approach for verifying that a hardware system hadn't been infected by persistent firmware malware. The authors had the system compute a function which had a known memory-optimal implementation which required the use of all the persistent memory available in the system (including firmware, etc.). Unfortunately I can't find the paper now.
Related project: <a href="https://betrusted.io" rel="nofollow">https://betrusted.io</a><p>(announced towards the 2nd half of the post)
That may be so but if I have to choose between open source software and closed software I know which one I trust more and I would assume the same goes for open hardware, in spite of the difficulties of transferring trust at the hardware level because of the parties over which you have no control. Of course if your threat model includes parties changing the masks of your chips then all bets are off but in general more openness is better and my implicit trust in people working on open source software and hardware is at a different level than the alternative.<p>If only because the ones seem to be driven by altruistic motives and the alternatives have already been shown many times to be willing to sell their - and your - soul to the devil for a price.<p>Open source hardware would need a verification and inspection method that reliably determines whether or not the manufacturer delivered what they said they would if you want that level of trust. And even then those tools could be compromised and so on.<p>To put it simpler: between say Intel or AMD and 'Bunnie's chip factory' I know which one I would trust more because with Intel and AMD I <i>know for sure</i> that there will be a bunch of misery included and with Bunnie I would at least know that he didn't include it himself and would do his best to avoid others doing it. Trust, eventually, is always going to be in people.<p>I'd love to see his 'non destructive method for the verification of chips' become a reality. It would be at least an interesting exercise to compare that what we have with what we should have.<p>And if funding is an issue, this is exactly the sort of thing where I would be very happy to throw money at a kickstarter.
I just got rid of my Google Home devices; gave them away as Christmas gifts and noticed half of those in the gift exchange didnt want any spying devices either.<p>Overall I really enjoyed using them especially the digital picture frame, but as long as they are spying devices to show you creepy ads (created by Google and Amazon) then Im not interested. I wish Apple would offer comparably tech at a normal price point. If not Apple another company whose is all about privacy and the device only connects to the Internet to download and store daily weather and traffic info. It would be a home network only device that listens when you summon it and it would alert you (via email or text) that a hacker is trying to hack it if it's Internet channel for downloading info is compromised.
I think there's always another layer of trust issues no matter how trustworthy your system is.<p>It might be you shouldn't even trust the physical environment, even power supply can be used to do evil things. Or radiation, even ambient temperature.<p>Don't forget code itself can affect the environment in unobvious fashion.<p>EDIT: My point is that we need to be aware security will never be a solved problem. We can't also consider security as a software-only issue, but have to have a holistic viewpoint considering the <i>whole</i> system.<p>There's of course the point where risk mitigation is not worth the cost. That's another matter.
Ideally, any piece of open hardware would be made by multiple competing companies and they would all be perfectly interchangeable. If one was discovered to be tampered with, you could easily switch, the offending company dies, and maybe some people are actually held accountable so others would be discouraged to try it again.<p>While the industry is still innovating, such an ideal world may not arise, but when things settle down and just about anyone can make a competitive version of any type of chip, it could, but only if we demand open hardware now to allow that competition to start forming.
> open hardware is precisely as trustworthy as closed hardware<p>Nice work but the conclusion is absolutely unwarranted:<p>Security is all about mitigating risk. With closed hardware, as much as software, it becomes much easier to implement backdoors <i>but also</i> hide who did it and when.<p>Unsurprising, a lot of closed source comes with spyware functions - look at the phone "app market".<p>By all means an FPGA is better than trusting a SoC, but this does not mean that all hardware is the same.<p>Management Engine is a good counterexample.
Single-source ISAs of the past relied on general industry verification technologies and methodologies, but open-source ISA-based processor users and adopters will need to review the verification flows of the processor and SoC <a href="https://semiengineering.com/will-open-source-processors-cause-a-verification-shift/" rel="nofollow">https://semiengineering.com/will-open-source-processors-caus...</a>
Great post. A well distilled argument as to the perceived virtues of open hardware and the actual root of the trust problem. The post strikes a great balance between showing the problem of complexity and yet highlighting a feasible step in the right direction. Kudos for not ignoring supply chain issues.
Wow, that talk on silicon implants was super interesting.<p>I commend him for continuing in this quest for trustable hardware. I more or less gave it up. I fear it wont be really possible until the tech has moved so far that we can produce silicon and PCB at home on open hardware machines...
I trust my sliderule. (This probably sounds like a snarky joke, so let me qualify it by saying I'm pretty serious.)<p>I'm an "Apocalyptic": I literally believe that these are the "End Times" and that our global civilization is about to tank (in ~10-50 years.) So I'm not so much worried about spooks in my chips as I am about being able to compute effectively at all, at all.<p>In that context, I think pretty seriously about what computer hardware will be available in a post-apocalyptic scenario. In that case chips will likely be worthless due to unavailability of datasheets.<p>The things that will work are sliderules and nomographs[0], henges and other geophysical "calendars", clockwork, fluidics, and relays. You <i>might</i> be able to make discreet transistors.<p>See the <i>Clock of the Long Now</i> mechanism: <a href="https://en.wikipedia.org/wiki/Clock_of_the_Long_Now#Design" rel="nofollow">https://en.wikipedia.org/wiki/Clock_of_the_Long_Now#Design</a> (Although a large pitch-drop[1] "water" clock[2] would be more reliable and much simpler.)<p>- - - -<p>Note that, if civilization <i>doesn't</i> collapse, the Trust Problem will become much worse as IoT advances, and, in the limit, <i>nanotech</i>... and you can't trust anything. Within the limits of physics, reality will become permeated with "ghosts", we will haunt the world with our own daemons. The Daemon-Haunted World. ("'The Demon-Haunted World: Science as a Candle in the Dark' is a 1995 book by astrophysicist Carl Sagan, in which the author aims to explain the scientific method to laypeople, and to encourage people to learn critical and skeptical thinking." <a href="https://en.wikipedia.org/wiki/The_Demon-Haunted_World" rel="nofollow">https://en.wikipedia.org/wiki/The_Demon-Haunted_World</a> )<p>- - - -<p>Maybe we <i>will</i> develop massive interlocking computer networks that respect (your idea of) your human rights, but that's certainly not a solid projection from current trends, eh?<p>[0] Image search for nomograph: <a href="https://duckduckgo.com/?q=nomograph&t=ffcm&atb=v60-1&iax=images&ia=images" rel="nofollow">https://duckduckgo.com/?q=nomograph&t=ffcm&atb=v60-1&iax=ima...</a><p>[1] <a href="https://en.wikipedia.org/wiki/Pitch_drop_experiment" rel="nofollow">https://en.wikipedia.org/wiki/Pitch_drop_experiment</a><p>[2] <a href="https://en.wikipedia.org/wiki/Water_clock" rel="nofollow">https://en.wikipedia.org/wiki/Water_clock</a>