Re: [Rats] Two types of secure attestation

[Kathleen Moriarty <[e-mail]>]

Hi Laurence,

I read your message as there only being 2 types of attestation as opposed
to what you stated in your follow on email, which better maps to the
restricted set in your first message.

Thanks,
Kathleen

On Tue, Nov 19, 2019 at 8:07 PM Laurence Lundblade <[e-mail]>
wrote:

> Hi Kathleen,
>
> Not sure I’m following your thought completely.
>
> From what I know of Authenticated Boot, the code signing formats are
> usually proprietary and idiosyncratic. The first stages of it are likely in
> true ROM (chip metal layer) and can be very architecture and system
> specific and would not use CoSWID or EAT.
>
> My comments below are about getting a system booted up to state where it
> known to behave as desired.
>
> Once it is up then signed CoSWIDs in EATs would come into play. They can
> be trusted because the attester and system SW known to have booted up
> correctly. Knowing who signed some SW listed in a CoSWID is only of value
> if you know the system SW did signature checking when it loaded the SW it
> listed. For example, everyone knows how Android app signing works, so
> listing the signer of an Android app is good useful information.
>
> Hope that makes sense in relation to your comment.
>
> LL
>
>
> On Nov 19, 2019, at 10:35 PM, Kathleen Moriarty <
> [e-mail]> wrote:
>
> 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
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
>
>

-- 

Best regards,
Kathleen