I am not an expert in software attestation but maybe the following bits of general knowledge can help you understand the security model of the Attestation app:
- every pixel device would not need to have the same private key hidden/stored inside its hardware; each one could have its own unique private key, with its the corresponding public key being cryptographically signed by a Google PKI server.
- Typically, setting up public-key cryptography infrastructures is done in multiple tiers. A company like Google might have a couple of PKI server delivering its keypairs to Pixel devices inside each factory; such servers would have their keypairs cryptographically signed by a region-wide Google PKI server whose access conditions are more secure; and such a region-wide server would itself have its keypair signed by a global Google PKI server stored and maintained at the highest tier of physical and software security. So you might have hundreds of factory-specific Google server certificates existing in the field (this is especially true since an admin would tend to generate a new certificate and invalidate the old one multiple times a year following PKI best practices), yet all of these certificates delivered on a factory floor and copied onto a device's hardware key store would be cryptographically tied to the single, top-level Google PKI certificate, which might have a 10 year validity period, and would be published widely to all interested parties through root certificate lists (which are usually found shipped with operating systems). Signed certificates have a kind of transitive property in this way, hence the expression chained up to a known root certificate
Hope this is relevant to you.