Trustable Hardware

This is an idea about really trustable hardware—say sufficient to digitally sign documents. The threat model is that you don’t trust the hardware manufacturer. There are processors that use only a few thousand gates. (The LGP 30 is said to have had only 113 vacuum tubes which would implement rather fewer gates. Its registers were recirculating tracks on the drum.) It would have perhaps 16K of ROM and 16K of RAM. It would have a 512 by 512 black and white pixel array. It would have at least enough ‘keyboard input’ to accept a secure yes-or-no response from the user. It would have a USB computer port but be programmed to only accept ASCI contracts or bit maps to be signed, and reply with the signature.

The screen would suffice to display the contract that the user may decide to sign. If the screen is too small then several passes are feasible but then it is necessary either for the user to read sequentially with no backtracking, or for the device to provide ‘random access for display’ to the contract from the untrusted computer on the other side of the USB. Merkle hash trees may solve this problem and I think that proposed hash standards provide necessary properties.

There are two security challenges:

Be transparent in its behavior.
Perhaps guard a private RSA key or alternatively accept entropy to generate the private key.

Perhaps the best way to provide transparent behavior is to be physically transparent. Relatively few people would be competent to judge the logical behavior of the device from its physical appearance, but arguments might well be made and reviewed that the complexity of its behavior is limited by its physical appearance. It would take a small expert committee to cover the attacks to be guarded against; circuits, logic, code, number theory. Several complementary safety arguments might be possible:

If the device sometimes performs its putative function and that function nearly fills the available visible ROM, then there may be no room for mischief.
The ROM data might be visible. Several historic memory technologies had this property.
The ROM might be readable externally via a visible physical read-only interface.

Key generation is problematic. The device might have the necessary compute power but we want to keep the code small. There are attacks where the attacker provides the confined generation software which pretends to find a pair of random primes, that are indeed not random. There are published deterministic prime finders whose performance can be ascertained. Their input is small and more easily kept in a safe place than the private key.

Some security problems are ameliorated by assuming that the small device is kept under continuous custody.

One may use the untrusted computer’s keyboard for entering a new contract, as long as you verify on the device’s display what you think that you typed.

So many places to hide: SMBus, Alert_Standard_Format, DMTF, I²C.