Security chip identity: the TPM
A TPM, the trusted platform module, is the part of a PC that keeps keys and proof: it can create a key whose private half never leaves it, it records a measurement of every stage the system loads at startup, it holds counters that only move forward, and it can sign a statement about all of that. It describes itself as well — the revision of the standard it implements, a code registered to its maker, the version of its own firmware. Websites meet it only through the passkeys it protects, installed software asks it directly, and a virtual machine has to answer for a part it does not have.
What the security chip is
The standard behind it is written by an industry body, and a PC can satisfy it in more than one way: a chip soldered to the board, a block inside a larger chip, or code running in a protected mode of the processor. The questions are the same in every case, and so are the answers: the family and revision of the standard, a short code registered to the maker, the firmware version of the part itself, the algorithms it offers. Two of the things it holds matter more than any of those. One is a set of registers the startup path writes into: each stage measures the next before handing over control, and a register can be added to but not, in ordinary operation, set back, so together they describe what the PC actually loaded. The other is a certificate the maker issued to this individual part, which is what lets the part prove that its keys came from a genuine one.
How websites see it
No interface in the browser opens the part. A page cannot read its maker, its firmware version, its registers or its counters, and nothing tells a script whether this PC started the way it should have. A page can ask whether the PC has a built-in authenticator at all, and that answer is a yes or a no. The rest arrives through passkeys: when a site registers one and the built-in authenticator makes the key, that key is normally protected by the part, and the site sees properties of the credential rather than of the chip — that the key stays in this PC rather than on something plugged into it, whether the person was verified before it was used, whether the credential is one that can be backed up elsewhere, and a counter returned with every signature. A site may also ask for attestation, a signed statement about what made the key, but the browser decides whether to pass it on and may ask the person first. The reticence is deliberate: the standard was written so that a site can learn that a key is well protected without learning which PC protects it.
How installed software sees it
A program installed on the system asks the part directly, through the interface the operating system provides. It can learn whether a part is present and turned on, which revision of the standard it implements, which maker and firmware version it reports, which algorithms it offers. It can read the measurement registers as they stand, and it can ask for a signed quote of them together with a value it chose itself, which a verifier compares against what this platform should have loaded. It can also wrap a key so that only this part, and only while the measurements match, can unwrap it. Licensing components and the protective parts of online services read exactly these fields when they decide whether they are running on a real PC.
Why it matters for a virtual machine
A virtual machine has no chip of its own. It gets whatever the virtualization software presents: nothing, or a virtual TPM, which is the same standard implemented in software on the host. Both answers say something. Where there is nothing, every check that expects the part finds an empty place that a current PC would not have. Where there is a virtual one, it describes its author rather than a maker of chips: the code it reports belongs to the virtualization product, the firmware version is that product's own, and the certificate that should lead back to a maker of chips is missing or self-issued, so a check that follows the chain ends nowhere. The measurements are as telling, because they record a virtual startup path instead of the firmware of a physical board. And whatever the answers say, the keys are not held in hardware: the state of a virtual TPM is data on the host, and it travels wherever a copy of the virtual machine travels. That is why the part belongs in a tour about hardware identity — its answers have to belong to the same PC as everything else.
What this stop of the tour shows
In this scene the camera moves to the board and opens the part's own description as a readable card: what it says about its revision, its maker and its firmware, beside the registers that hold the startup measurements and the counters that only move forward. The card is drawn on the page rather than painted into the video, so it stays legible in every language and can be read without the animation. The next stop asks the processor to describe itself.
| Field | What it says |
|---|---|
| Specification revision | The family and revision of the standard the part implements. It decides which algorithms and which commands software can use. |
| Manufacturer | A short code registered to the maker of the part. A virtual TPM reports the virtualization product here. |
| Firmware version | The version of the code inside the part. Makers issue updates for it, so the value moves over the life of a PC, and it has to fit the maker and the model. |
| Endorsement certificate | A certificate the maker issued to this individual part. It is unique and permanent, so proofs are made with a separate key certified against it rather than with the certificate itself. |
| Measurement registers | Registers that each stage of the startup extends with a measurement of the next. They describe what the PC loaded, not what it claims about itself. |
| Counters | Values that only move forward, so that a saved state cannot be replayed as the current one — which is exactly what a copy of a virtual machine does. |