[Rats] Two types of secure attestation

[Laurence Lundblade <[e-mail]>]

Fundamentally, I think there are two ways that an attestation verifier comes to know that a device / entity is running approved SW and will behave as desired.

TPM based
Originates in the PC world where the end user had to be able to choose the system SW
Has a TPM that performs a general measuring function
Has an attestation signing key for signing measurements that is kept secret by the TPM
TPM is generic as it can be used for PC’s, routers, IoT devices
Authenticated boot is optional
Uses a staged boot architecture where each stage must measure (hash) the following stage
Hashes fed into the TPM
TPM generates the attestation of the registers holding the hashes
Device cost raised by cost of TPM part
The verifier must run a parallel set of measurements (hashes)
Verifier is complex

Authenticated Boot based
Origins in mobile phone, TEE and DRM world where the user can NOT choose the system SW
Authenticated boot is required
Uses a boot ROM that really is a ROM, probably in silicon (not flash), that can NOT be changed
Boot ROM verifies the SW that is loaded, particular the top privilege (e.g. kernel) SW
A good implementation has anti-rollback to prevent old versions of SW from being run
Has an attestation signing key that is programmed in fuses or possibly in flash
Has a HW block that prevents access to the attestation key unless authenticated boot succeeds
Only top privilege SW can use it
Attestations are created in the top-privilege SW
Simply signing a nonce proves the device is running approved SW
Easy to add other claims in —> EAT
Device cost raised by need for secure key provisioning in the factory
Verifier is very simple
Just needs to verify the signature and nonce

Both provide acceptable security for their use cases and are broadly in use.

RATS needs to support both.

LL