Tamper Resistance?

We consider here how one can tamper with a machine via its external ports.

How much hardware within a system belongs to the TCB? The industry has gained greatly from the ability to plug PC cards and PCI devices into computers on whim. Most OS software has been so gullible that maliciously crafted high level signals suffice to compromise the system entirely within the hardware specs. The rogue need not learn the crafts of the circuit engineer. This note is about vulnerabilities to a malicious hardware engineer.

We examine some risks with untrusted PC cards and PCI devices. On most current systems these cards are bus masters with the same ability to read and write RAM as the CPU.

The official interface specs are expensive and I have not recently studied them. I do recall, however, that there are several levels of spec:
LevelDescriptionThreatRogue’s investment
Circuit This specifies the voltage and impedance required to communicate with the system bus. It specifies the difference between signal and noise. One man’s noise, however, may be the rogue’s signal. Custom circuit design
Logical signal sequences—Pin Specs These specify when clean signals on the pins to the card belong to the card, and also when it is permissible to assert a signal. The rogue card may read addresses and data that belong to another card, or even the CPU. Custom logic design.
Messages These spell out what messages from the system are meant to convey to the card that the card should concern itself with which areas of RAM. The Cardbus spec spells out the semantics of interface signals to the card relating to where the card may read or write. It is up to the card to conform. A rogue card may not. A rogue card may concern itself with other areas of RAM, either reading or writing there. microcode
Card Identification There are protocols for a card to identify itself with a structured name, including identification of the manufacturer. The rogue card can lie. microcode
I omit attacks such as asserting signals impermissibly as these are likely to be observed by either damaging other equipment or at least damaging its operation.


I think that Sun’s SPARCs introduced the IOMMU which serves as an intermediary between cards and the system bus. It translates RAM addresses for access by the cards, as the MMU (Memory Mapping Unit) translates addresses for programs executed by the CPU. This translation also affords access control.

This allows a secure subsystem to exclude all PC cards or all PCI devices from the TCB except, perhaps, those with rogue custom circuit design or logic design.

It would seem difficult to retrofit an IOMMU to extant OSes not designed with that in mind.

AMD’s IOMMU design addresses most of these issues. (Regarding 2.1 “The IOMMU may optionally include support for remote IOTLBs. A device with IOTLB support can cooperate with the IOMMU to maintain its own cache of address translations.” If “remote IOTLBs” means hardware ‘outside the system’ then we have a problem. Any IOTLB is in the TCB where ever it is.)

See obscure reference to IOMMU here. Here is Intel’s definition of their IOMMU. They think it is only for virtualization.

Who is the bad guy?

Part of the motivation of TCPA is to protect the user and the threat is that the user unwittingly installs a rogue card. This requires a fancier plan as the installer is not the rogue. Another part of the TCPA thrust is to assure content owners that some particular platforms will do their part in protecting their interests. In this case the owner may be the rogue.

New Proposed Interfaces between Chips

I have looked briefly at RapidIO and HyperTransport. HyperTransport calls for a standard method for accessing RAM but also provides for disabling that ability, which is the power-up default. I don’t know whether it can support legacy drivers with this disabled.

Neither document mentions hot swapping but they leave the impression that such issues are the realm of the legacy bridge to old cards. There is room here for security design bugs, and also an opportunity to solve some of these problems.

PCI-X and PCI Express (PCIe) are two proposals that are not yet open. (As of 2015 Dec PCI Express still has a paywall before the meat but here is a book. tutorial) Their overviews stress legacy OS compatibility. This would not preclude new modes that controlled RAM access by individual units. Here are recent worries about the PCIe specs.

Of Microsoft’s Palladium plans, Seth David Schoen says that: Even PCI DMA can’t read or write memory which has been reserved to a nub’s or TA’s use (including the nub’s or TA’s code). This memory is completely inaccessible and can only be accessed indirectly through API calls. The chipset on the motherboard is modified to enforce this sort of restriction. I think that they plan to protect RAM by a per page access bit. DMA to each physical page is controlled by a bit for that page.

External: Read it and weep. New modes.


Today the most visible quest for tamper proof machines aims to protect high value data such as a current Hollywood release. To do this you must prevent every personal computer that holds the data from tampering. The hardware cost is proportional to the number of such computers and this is thus a daunting quest. For some purposes only one or a few computers need be protected and this is much more plausible.

A Generalization

Some purposes for which we seek tamper proof hardware may be met by including a person or persons in the ‘unit’ along with the computer. This is not a technical solution in the sense of most of these pages, but the logic does follow. An ordinary computer, running a secure kernel, carried by someone competent and motivated to keep others from tampering with said hardware, may be said to provide a tamper proof unit for purposes this page.