Re: [Rats] Two types of secure attestation

[Anders Rundgren <[e-mail]>]

On 2019-11-19 14:26, Laurence Lundblade wrote:
> 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.

Yes, it seems that the IETF activity around trusted computing for unknown reasons intends ignoring the attested-session-key-scheme where sub-attestations are based on rolling MACs.
FWIW, this is one of the pillars of the Open Banking Wallet concept although it is not mentioned in this writeup:
https://github.com/cyberphone/doc/blob/gh-pages/payments/dual-mode-open-banking-api.md#background

Thanx,
Anders
https://github.com/ietf-teep/architecture/issues/52

>
> *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
>       o Has an attestation signing key for signing measurements that is kept secret by the TPM
>       o 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
>       o Hashes fed into the TPM
>       o 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)
>       o 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
>       o Uses a boot ROM that really is a ROM, probably in silicon (not flash), that can NOT be changed
>       o Boot ROM verifies the SW that is loaded, particular the top privilege (e.g. kernel) SW
>       o 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
>       o Has a HW block that prevents access to the attestation key unless authenticated boot succeeds
>       o Only top privilege SW can use it
>   * Attestations are created in the top-privilege SW
>       o Simply signing a nonce proves the device is running approved SW
>       o Easy to add other claims in —> EAT
>   * Device cost raised by need for secure key provisioning in the factory
>   * Verifier is very simple
>       o 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
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats