Open Fabs

Steve Kinney admin at pilobilus.net
Wed Jul 29 21:11:06 PDT 2015


-----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 at 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-----



More information about the cypherpunks mailing list