Re: [Rats] Two types of secure attestation

[Henk Birkholz <[e-mail]>]

Now I am confused again. Why should a Verifier ever create Attestation 
Evidence? Do yo mean Attestation Results?

If I understand you correctly, the fact that the EAT can be signed is 
due to the fact that authenticated boot was successful, right? What 
happens if the authenticated boot was not successful? Can you still 
create EAT? With different boot state?

How do you know that the boot state was not tempered with and the device 
is "lying" to you? I think you are describing implicit remote 
attestation, where you can only sign something if authenticated boot was 
successful. Is that your use case you are describing?

On 21.11.19 09:06, Laurence Lundblade wrote:
> In the non-TPM style attestation I’m describing, /no/ measurement is 
> transmitted from the attester to the verifier. It is not necessary to 
> send one. The trust in the attester is automatic, immediate, real and 
> highly valuable.
> 
> This is why the sample simple EAT in the draft there is no measurement 
> in the EAT attestation evidence:
> 
> {
>     / nonce (cti) /            7:h'948f8860d13a463e8e',
>     / UEID /                   8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f',
>     / boot_state /            12:{true, true, true, true, false}
>     / time stamp (iat) /       6:1526542894,
> }
> 
> 
> In this non-TPM style attestation there is hashing of code booted as 
> part of secure boot implemented in the boot ROM, but that all happens 
> inside the boot sequence and never manifests outside of it (I also do 
> not think it is helpful to refer to this part of the boot ROM as a 
> “verifier” in this context because it is not the same as a RATS verifier 
> that produces attestation evidence, is remote and such).
> 
> LL
> 
> 
>> On Nov 21, 2019, at 3:22 PM, Henk Birkholz 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Laurence,
>>
>> I think that is a way better scope (maybe this thread in itself had 
>> some scope creep) to describe it.
>>
>> I think it is rather obvious that the complexity of the appraisal 
>> process (the thing the Verifier does) depends on what you want to 
>> verify and how complex the evidence and the Attester are.
>>
>> If a simple Attester (such as a small thing, e.g. Car ECU, or 
>> Constrained Node Device) conducts authenticated boot, Attestation 
>> Evidence is fairly simple. It could be a single hash (the measurement 
>> after boot), or the most relevant part could be a signature based on a 
>> shielded secret in the thing. Both lead to very simple Attestation 
>> Evidence content and to very simple appraisal processes.
>>
>> The more thorough your measurements and the more complex the Attester, 
>> the more complex is the appraisal process. This is true for every RATS 
>> - TPM, fTPM or other TEE.
>>
>> Maybe this is single scope is a better way to describe the matter at hand?
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>> On 21.11.19 08:11, Laurence Lundblade wrote:
>>> What I really care about here that this working group accepts the 
>>> non-TPM style of establishing trust in the attester by the verifier 
>>> as having equal stature with TPM style.
>>> In the non-TPM style there is no need for any back and forth protocol 
>>> and no need for the verifier to do anything with measurements taken 
>>> during boot. The verifier just needs to know that it is of this 
>>> non-TPM style and attestations are immediately trusted.
>>> (It would be cool and useful to line up all the terminology and 
>>> taxonomy, but that seems like about six months work, so I’m not after 
>>> that, so no line-by-line replies from me)
>>> LL
>>>> On Nov 21, 2019, at 2:50 PM, Henk Birkholz 
>>>> <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> to be honest there now came so many different topics up in this 
>>>> thread that I am unable to connect all the dots here.
>>>>
>>>> I'd like to correct a few points of the initial statement based on 
>>>> Trusted Computing Group procedures, if that is okay:
>>>>
>>>> The fundamental discrepancy I see is the differentiation between 
>>>> "TPM based" and "Authenticated Boot based", because:
>>>>
>>>> => TEE,fTPM,pTPM,and vTPM enable Measured or Authenticated Boot
>>>>   Differentiating them by the terms above seems impossible.
>>>> => TPM based authenticated boot starts with S-CRTM (Static Code Root of
>>>>   Trust for Measurement). One type of this S-CRTM is immutable ROM
>>>>   code.
>>>> => There is no one generalized measuring function in the TPM. There are
>>>>   32 two (in practice often 24) highly specialized measurement scopes
>>>>   that can be dynamically assigned and are quite modular (Profiles
>>>>   assign the semantics for different domains of application.
>>>> => The TSS/TPM architecture supports layered attestation (which I think
>>>>   is what you mean by "staged boot architecture", but "each stage" does
>>>>   not simply "hash" the "next stage" it is again a dynamic and modular
>>>>   measurement framework, hashes are not "stored" but fed into TPM
>>>>   provided folding hashes (a so called "extend" primitive operation).
>>>> => corresponding verifies do "run a parallel set of measurements".
>>>>   Complex, touring-complete, non-deterministic execution environments
>>>>   (e.g. REE or TEE) can require the "replay" of measurement logs, which
>>>>   include system event and platform specific state change measurements.
>>>>
>>>> In summary, I think the basis for the comparison is a bit off :-)
>>>>
>>>>
>>>> IHTH,
>>>>
>>>> Henk
>>>>
>>>>
>>>> On 21.11.19 07:14, Laurence Lundblade wrote:
>>>>> I wrote this email because of side conversations with people that 
>>>>> seemed to be implying the second type I described was invalid and 
>>>>> insecure with the implication that EAT attestations could not 
>>>>> trusted unless a TPM-based attestation was done first.   This is a 
>>>>> gross mischaracterization. This working group can not operate on 
>>>>> that basis.
>>>>> I also wrote to facilitate understanding of the two main technology 
>>>>> orientations of participants.
>>>>> I should have titled this better.
>>>>>  * This is about how/trust in the attester by the verifier /is 
>>>>> established.
>>>>>  * Two popular approaches are described, but not to the exclusion of
>>>>>    other approaches.
>>>>> LL
>>>>>> On Nov 21, 2019, at 5:11 AM, Smith, Ned <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>> There are some misrepresentations in the analysis below (I’ll 
>>>>>> comment inline below using [nms] delimiters). In general, I don’t 
>>>>>> see attestation types as being binary. Dave Thaler’s chart / truth 
>>>>>> table in another thread seems to suggest this as well given there 
>>>>>> are many different types of attesting environments (aka roots of 
>>>>>> trust).
>>>>>> It might make sense to have discussion around claims that apply to 
>>>>>> attesting environments vs. claims that apply to attested 
>>>>>> environments? The important security property of attesting 
>>>>>> environments is they often are regarded as “trusted” meaning there 
>>>>>> isn’t some other attesting environment that vouches for it.
>>>>>> Associating claims to attesting environments often takes a 
>>>>>> different from attestation (as represented by the roles / arch 
>>>>>> models); namely using certificates issued by product vendors (what 
>>>>>> the arch has called ‘asserters’). Certificates typically contain 
>>>>>> identity claims but could contain additional claims. Vendors could 
>>>>>> also sign assert claims by signing a document that asserts them. 
>>>>>> These could be manifests, attribute certs, identity certs with 
>>>>>> claims extensions and possibly even JWT/CWT (tokens). I haven’t 
>>>>>> seen a use case for vendor issued tokens however. Possibly PKI 
>>>>>> will transition from X.509 based to Token based at some point in 
>>>>>> the future, but I expect it will take a while. Vendors issuing 
>>>>>> (signing) manifests seems reasonable since many already create 
>>>>>> manifests for software distribution also called packages / 
>>>>>> bundles. The workflow for ‘reference values’ would not be much 
>>>>>> different than for creating a SW update manifest.
>>>>>> *From:*RATS <[e-mail] <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>> on behalf of Kathleen Moriarty 
>>>>>> <[e-mail] 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>
>>>>>> *Date:*Tuesday, November 19, 2019 at 6:00 PM
>>>>>> *To:*Laurence Lundblade <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>> *Cc:*"[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>" 
>>>>>> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>> *Subject:*Re: [Rats] Two types of secure attestation
>>>>>> 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] <mailto:[e-mail]> 
>>>>>> <mailto:[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] 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[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] <mailto:[e-mail]> 
>>>>>>>> <mailto:lgl@island-resort..com>> 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
>>>>>>>>> [nms] Not sure what relevance to attestation should be ascribed 
>>>>>>>>> because of how TPMs originated.
>>>>>>>>> ·Has a TPM that performs a general measuring function
>>>>>>>>>
>>>>>>>>>          + Has an attestation signing key for signing measurements
>>>>>>>>>            that is kept secret by the TPM
>>>>>>>>>
>>>>>>>>> oTPM is generic as it can be used for PC’s, routers, IoT devices
>>>>>>>>> [nms] Profiles for how to adapt TPM for use in specific 
>>>>>>>>> platform classes is generally required.
>>>>>>>>> ·Authenticated boot is optional
>>>>>>>>> [nms] I think the industry also uses the term ‘secure boot’. 
>>>>>>>>> TPM supports attestation (of the boot sequence) while a secure 
>>>>>>>>> boot approach doesn’t imply attestation is needed/used.
>>>>>>>>> [nms] Boot behavior is more a property of the Root of Trust for 
>>>>>>>>> Measurement (RTM) than a TPM. There are many types of RTM 
>>>>>>>>> technology most simply it is a boot ROM.
>>>>>>>>> ·Uses a staged boot architecture where each stage must measure 
>>>>>>>>> (hash) the following stage
>>>>>>>>> [nms] Boot architecture is determined by the type of device / 
>>>>>>>>> platform not the TPM. Staged boot sequences are fairly common 
>>>>>>>>> across the industry. Hence the term ‘bootstrap’.
>>>>>>>>> oHashes fed into the TPM
>>>>>>>>> oTPM generates the attestation of the registers holding the hashes
>>>>>>>>> ·Device cost raised by cost of TPM part
>>>>>>>>> [nms] Not sure how this is relevant to RATS
>>>>>>>>> ·The verifier must run a parallel set of measurements (hashes)
>>>>>>>>> oVerifier is complex
>>>>>>>>> [nms] as compared to what?
>>>>>>>>> *Authenticated Boot based*
>>>>>>>>> ·Origins in mobile phone, TEE and DRM world where the user can 
>>>>>>>>> NOT choose the system SW
>>>>>>>>> ·Authenticated boot is required
>>>>>>>>> oUses a boot ROM that really is a ROM, probably in silicon (not 
>>>>>>>>> flash), that can NOT be changed
>>>>>>>>> [nms] This is true for platforms using a TPM as well.
>>>>>>>>> oBoot ROM verifies the SW that is loaded, particular the top 
>>>>>>>>> privilege (e.g. kernel) SW
>>>>>>>>> [nms] Verification implies the ability to determine boot code 
>>>>>>>>> integrity. This is common to platforms that use a TPM.
>>>>>>>>> oA 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
>>>>>>>>> [nms] This is commonly true for TPM based attestation 
>>>>>>>>> implementations.
>>>>>>>>> oHas a HW block that prevents access to the attestation key 
>>>>>>>>> unless authenticated boot succeeds
>>>>>>>>> [nms] This is also true for solutions that wish to implement 
>>>>>>>>> secure boot using a TPM.
>>>>>>>>> oOnly top privilege SW can use it
>>>>>>>>> [nms] TPM attestation keys have restrictions on use as well.
>>>>>>>>> ·Attestations are created in the top-privilege SW
>>>>>>>>> oSimply signing a nonce proves the device is running approved SW
>>>>>>>>> [nms] The security properties of the signing key (attestation 
>>>>>>>>> key) are a function of the claims that the manufacturers make 
>>>>>>>>> about the environment that protects the key. This is true for 
>>>>>>>>> TPM as well as any other root of trust / attesting environment.
>>>>>>>>> oEasy to add other claims in —> EAT
>>>>>>>>> [nms] relative to what?
>>>>>>>>> ·Device cost raised by need for secure key provisioning in the 
>>>>>>>>> factory
>>>>>>>>> ·Verifier is very simple
>>>>>>>>> oJust needs to verify the signature and nonce
>>>>>>>>> [nms] The verifier is also integrated into the boot code. These 
>>>>>>>>> verifiers need to be provisioned with boot state policies and 
>>>>>>>>> so forth. Secure boot is an example of the combining of 
>>>>>>>>> Attester and Verifier roles.
>>>>>>>>> Both provide acceptable security for their use cases and are 
>>>>>>>>> broadly in use.
>>>>>>>>> RATS needs to support both.
>>>>>>>>> [nms] In what ways does RATS not support both?
>>>>>>>>> LL
>>>>>>>>> _______________________________________________
>>>>>>>>> RATS mailing list
>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/rats
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>> Kathleen
>>>>>>>> _______________________________________________
>>>>>>>> RATS mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/rats
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Kathleen
>>>>> _______________________________________________
>>>>> RATS mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/rats
>>>>
>>>> _______________________________________________
>>>> RATS mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/rats
>>
>