facilities, and having them certified by third parties before issuing an order.
If we realize that trusted cores, during the personalization phase, can be
loaded with money, as is the case with prepaid tokens, then no wonder the
manufacturing plants look like fortresses. They typically have no windows, and they
have armored doors, secure enclosures within secure enclosures and the like. As
one can see, it is not quite the usual computer plant.
Speed of
production and yield are obvious success factors, as well as flexibility in
procurement, i.e. multi-sourcing, and the capability to affect the same
supplies to various purposes. For example, the move to flash memory in trusted
cores is in part due to the fact that contrary to the read-only memory it
replaces, flash can be changed during the manufacturing cycle to adapt to new
demands. Of course, this raises the security concern of whether it can be made
as immutable as ROM. To give an idea of how those various
elements of manufacturing affect trust, let us consider the requirement for
speed of production.
As we’ve
discussed, in today’s model of secure core systems, a necessary step is mass
personalization. This means that each trusted core has to be filled with
confidential information specific to the application and to the future owner.
For example, for payment systems the trusted core must receive confidential
information regarding the digital authentication of the payment organization.
One way to do accomplish this is first to create a complete trusted core, then
use the trusted core mechanisms to enter data piece by piece. The benefit to
this approach is that it is reusing security mechanisms already in place.
However, in a mass production mode it takes too much time to be economical. A
way to do it fast is to write all the data at once into the trusted core.
However, to retain trust this requires defining additional security mechanisms,
which also have to be audited, certified and tested, just like other trusted
core mechanisms. As we can see, the speed requirement affects directly the
trust mechanism, i.e. it makes trust assertions much more expensive, even if at
the end the total cost of production is lower. Finally, we should mention
briefly the issue of distribution.
When the trusted
core leaves the manufacturing plant, it is very important to protect it until
it reaches the final distribution center. In actuality, the distribution looks
less like a regular computer shipping operation than a bank transfer operation.
This is because at this point, the trusted core may contain critical
information related to further personalization, and must reach its destination
intact. Hence, trust has to derive from the transport mechanism and associated
processes.
Trust is
recursive. Trust applies to trust and trust derives from trust. In fact, any
mechanism put in place to warrant trust is itself subject to trust. So trust is
never complete. A good illustration is trust prioritization. We have seen that
trust comes at a cost, and that we can’t trust everything less we be paralyzed.
In some cases, cost simply overrides any trust concern. So, if we need to
establish trust in an implement, we’d better know why this implement is
important. Since trust is recursive, prioritization itself needs to be trusted,
as do the mechanism of trust prioritization, and so on. However, there needs to
be an end to the process, otherwise no action could occur. As an aside, we
might note that within human cognition, this is the place were emotion enters
the trust equation. Within computer systems there must be an ultimate point of
trust. In the abstract, this situation is barely distinguishable from
randomness, assuming that we trust that randomness exists. This is, of course,
something of a debatable proposition in itself, particularly in information and
quantum theory circles, as detailed in Science and Ultimate Reality: Quantum
Theory,
|