-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/2015 10:48 PM, grarpamp wrote:
On Wed, Jul 29, 2015 at 9:47 PM, Steve Kinney <admin@pilobilus.net> wrote:
That's exactly what I'm talking about: Essentially taking over the production process and working alongside facility staff, with particular attention to choke points where validation is both possible and productive. ISO quality programs include provision for onsite participation by clients
I submit the above is moot... you're taking your chip design in on your USB, happy as a clam to be the one to insert it into their computer, pull it up on their screen, and watch the whole thing play out before your eyes... on down the line till out pops a chip in your hand, yay!
That's not what I have in mind at all. Everything that touches the production process would have to be isolated and audited. In practical terms, that would mean bringing the computers in question in from offsite, with relevant software already installed and validated. In the context at hand, watching the whole thing play out would consist of directing the whole process one step at a time, per a procedure created in collaboration with the contractor's engineering and QA departments. Optical masks and/or equivalent data files would be handled by client personnel and retained for validation. The chips that pop out would be under very stringent property control, and quite a lot of them would be torn down and thoroughly analyzed "at home" to validate the run.
But you failed to realize their computer and software probably wasn't made by them, nor has any open to you audit crosscheck been wrapped around it or it's operators and maintainers... on down the line. You can carve a stick with a knife but you can't really build a trusted cpu with an untrusted cpu.
If the goal is to build an open trusted fab, you must build an open trusted fab, by and with the hard and different philosophical mofos who refuse to concur unless each step of design, build and operation is plainly validated. Otherwise you're just selling tourist tickets to the theme park.
Just like doing it at an existing commercial facility, with the added advantage of much better control of physical access, hardware, etc. at the dedicated facility. Whether that advantage would be worth the extra costs, vs. real security improvements, depends on how reliable the post-production tear down and analysis of end product components is considered. "A difference that makes no difference is no difference." If it really is impossible to build a trusted CPU with an untrusted CPU, then it is not possible to build a trusted CPU. Fortunately, trust is not an absolute and there are ways to build relatively trustworthy systems from relatively untrustworthy components. A quote to the effect of "I do not care who votes, I only care who counts the votes" comes to mind but I'm too lazy to look it up right now.
This is old school TCSEC / CC applied to manufacturing.
You have cost efficiency in that the knowledge of tool and chip making already exists. You use that savings to offset cost of rebuilding with TCSEC. As opposed to trying to impart trust upon existing systems which is prohibitive.
Somewhere, the rising curve of security costs will cross a falling curve of security risks, and that's as good a place as any to draw a line.
Trust is not defined by a point on a cost curve.
I think that in the engineering and business worlds, trust is always a point on a cost curve. When Trust and Security are considered as absolutes, the costs of maintaining them rise exponentially until the protected assets die of resource starvation. Civilization as we know it is presently following the path of demanding absolute security, provided by rulers vested with absolute trust, to early termination. Getting more on the practical business of making IC chips into the public domain and widely distributed, enabling faster and decentralized recovery of today's industrial capabilities, is one of the benefits of open hardware development projects. The objectives of an open IC project include providing protections against institutional sabotage, but also the creation of protocols, documents and data that can be re-used and improved over time. Policies and protocols necessary to assure adequate transparency, including repeatability, would amount to enlarging the GPL ecosystem to encompass computer hardware as well as software. If such a project can't produce products that are cost effective for end users, it will remain at most a theme park ride for misguided investors. The "high security" angle looks like a place where potential customers and nearly off-the-shelf capabilities meet. :o) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVuaPYAAoJEDZ0Gg87KR0LVJQQAJVUA0uR0eWYzUkqB0+b1HQu kBejHQss7jyLU4qhCIfKaoVF7bZcnIZLydT+BP/OCybDHisqlKcK5lI/1Ic8s1w+ uAY78xV2c+3N4IMRe1CgkirGDGP9PUOZCn/1czme66yqPWtHioY+ayh76QDZIz3q PPSt1j7XnodgTJoHLR1uc//vlBo8gQAgja9m7q9k6U72gl4EXVS+4Qm8TN5fMFbJ wLE8q7YqAOw8iU5UIa7vO767OqxOsfXoghoyis5PhkHtQKCW24SapgEBosl+uuSw s+WsS92rYlwigPXMIec33WBjstxK6Z10aebbW1BjZce/r9GM1cX24vs4vN4tvQ1a jpxeazQGhp6xUKi9m5UZ0d3uoZtSCgfyoIXiTaa+aZ3VGWt+OyxgqjG0HzeIh2Kv qa0r+JGaCa59atzwfNEs2DYld70atUIeebNBYiwWapumX7MSqPgqYbBenK+lodI6 5BaO97iHeayLjjVUPL7BeVpFsk/XGMw7QT5mwPz8JSCv/jyjQPtihkFOmB9jXTIc DfHd72IgXLkXFr32HelZjLn7RQsiJwwafU3Eki0WdciQ0CvwmsZuB530uifnKy6b EqvOAGFvqpc1ahvonnwgZ7Bg/0GhvbIzuLab0PamMUJ7G88HtAZbgRSiVWKPY/Jk zm2xMpzVtMWnAGnRnjBj =qtx4 -----END PGP SIGNATURE-----