Hacker News Reader

Comment by Godel_unicode | Hacker News Reader

The logical end-state of this train of thinking is tamper-resistant key generation and storage, with fully published sources and audited assembly line production.

Except then they need to ensure that all the equipment on their line was produced by trusted suppliers with the same level of disclosure. Ditto all software which touches anything in the manufacturing process. It's turtles all the way down, see also "on trusting trust".

View on HN

Or just do it with open code & hardware on an ASIC whose process node is verifiable by eye with a microscope against a reference image after samples of it are decapped. Either by the owner or numerous third parties. You make it sound much harder than it is unless they're using unverifiable technology. In that case, it might be pretty hard. ;)

That's ridiculous. People can't reliably produce good implementations of crypto software, and you suggest they design and verify ASICs? My point was that security is about understanding and accepting, not foolishly trying to eliminate, risk.

Just a few of the mountains which need climbing: First, you'd need a (actually) random sampling not just one (keep in mind any ASIC you test is likely a write-off due to tamper-resistance). You'd also need a high assurance supply chain to ensure your verification isn't premature (as well as sufficient levels of tamper resistance/evidence). You'd further need to verify the software around this hypothetical ASIC is free of bugs. You're restricting yourself to software which can be performant on older slower process nodes. You (almost certainly not an ASIC company) need to have an in-house ASIC shop, or you need to vet an external one (sounds cheap and easy for the average business). In fact, you need vetting of your internal staff at all stages of this process.

You are making this seem _much_ easier than it is. There's a reason this product, which there is definitely a market for, doesn't exist (and that reason is much more mundane than the cryptolluminati not wanting it to "get out"). Consider that Google did something like what you're suggesting. It took them years (and they're Google), what chance does the average person/SMB have?

"That's ridiculous. People can't reliably produce good implementations of crypto software, and you suggest they design and verify ASICs? "

You suggested that they verify or perfect every person or thing in the entire supply chain. That was ridiculous. I suggested they or trusted, third parties simply verify an ASIC. That's doable. Matter of fact, people already tear down and image ASIC's on older nodes for fun. A number of companies and labs tear down modern ASIC's to reverse engineer them for understanding or finding patent violations. ChipWorks is top company in that space.

So, it's my recommendation of a practice that's being done right now vs you're recommendation to change everything in an impossible way. I stand by mine.

You should reread my post in the context of the post I'm replying to. It's not a recommendation, it's an explanation of where the poster's "how can we trust their manufacturing process" question leads. People tend to throw out those types of questions as reasons to not use e.g. Yubikey without thinking through how they would want such proof given to them. People also reverse x86 binaries for profit, but suggesting that RandomSaaS do so to their compiler to check for backdoors would be equally a waste of their time and money.

Just because something is technically possible doesn't mean the average company should do it. Security is about trade-offs.

" It's not a recommendation, it's an explanation of where the poster's "how can we trust their manufacturing process" question leads. "

If it's that, then it was a decent attempt at explaining how big the problem is if one wants to trust every step. Good news is you don't have to as I illustrated. Just a small number of third parties doing a tear down. They can even be enemies reviewing same thing with equipment made in opposing countries for best effect. Old trick of mine. :)

I suppose you could use an fpga, but you still need to audit the assembly line. It's not simple, and you will place trust somewhere.

Use my same trick but with FPGA's. Those on older nodes barely have any logic gates, though. Another trick for the wealthy is using the latest node that's so cutting-edge they can barely get stuff to work at all. Hard to do some subversion of a black box if state-of-the-art verification barely made that black box functional to begin with.

So, more turtles waiting down there....

In the end, it is the attempt to create a positive proof in a system that is not a defined formal system (real world vs pure mathematics). Impossible - as you say, you need to place your trust somewhere. Even if it's your own abilities. But that trust can always turn out to be not justified.

You need to make a simple interpreter or processor that's verified by eye, brute force, or mathematically. An old example was FM9001 with newer ones being VAMP (open?) and AAMP7G (proprietary). You do that on a node you can verify by eye. You verify a random sample of the pile you ordered by eye. You use it with cheapest, simplest, oldest parts for input and display that you ordered in obfuscated way so they don't think source of order was important. Then, you have hardware you can trust to do the rest of the calculations for trustworthy hardware or software that's much better. Including image recognition software to semi-automate your job of spotting things that don't below in images of chips. ;)

Reply on news.ycombinator.com