Re: [Rats] Two types of secure attestation

[Kathleen Moriarty <[e-mail]>]

Hi Laurence,

Where does the code signing example fit in that you gave as it's not really
an attestation, but could be useful in the format of an EAT/CWT?   This
questions considers the CoSWID discussion as well as another example you
had in your slides later (which was really the same) on just validating the
code was signed by the expected private key?  Should that be called an
attestation or just using the format for signing?  You might add claims
in above what's in the CoSWID and use the nesting of EAT/subdomains as well
as perform remote verification.

Thanks,
Kathleen

On Tue, Nov 19, 2019 at 8:26 AM Laurence Lundblade <[e-mail]>
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.
>
> *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
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>


-- 

Best regards,
Kathleen