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.

Modeling Trust

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,

Book available at Midori Press (regular)
Book available at Midori Press (signed)
Book available at Amazon (regular)