Subject: [Rats] Two types of secure attestation

From: Laurence Lundblade <[email-masked]>
Date: Tue, 19 Nov 2019 21:26:02 +0800

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 19 Nov 2019 09:35:23 -0500

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 <[email-masked]>
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
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 19 Nov 2019 16:25:01 +0100

> 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
>
>
>   * 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
>
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 20 Nov 2019 09:06:58 +0800

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 19 Nov 2019 20:59:33 -0500

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 <[email-masked]>
wrote:

> 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.
>
> 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.
>
> 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
>>    - Uses a staged boot architecture where each stage must measure
>>    (hash) the following stage
>>       - Has a HW block that prevents access to the attestation key
>>       unless authenticated boot succeeds

-- 

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 20 Nov 2019 21:11:50 +0000

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 <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
Date: Tuesday, November 19, 2019 at 6:00 PM
To: Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen,

LL

On Nov 19, 2019, at 10:35 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Thanks,
Kathleen

On Tue, Nov 19, 2019 at 8:26 AM Laurence Lundblade <[email-masked]<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
o    TPM 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’.
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
[nms] Not sure how this is relevant to RATS
·         The verifier must run a parallel set of measurements (hashes)
o    Verifier 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
o    Uses 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.
o    Boot 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.
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
[nms] This is commonly true for TPM based attestation implementations.
o    Has 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.
o    Only top privilege SW can use it
[nms] TPM attestation keys have restrictions on use as well.
·         Attestations are created in the top-privilege SW
o    Simply 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.
o    Easy 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
o    Just 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.

RATS needs to support both.
[nms] In what ways does RATS not support both?

LL
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

--

Best regards,
Kathleen
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

--

Best regards,
Kathleen

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 21 Nov 2019 05:11:47 +0100

And then you have the outcome/action of an attestation which I guess currently is "Pass" or "Fail".

As shown in https://cyberphone.github.io/doc/research/session-based-remote-attestation.pdf "Pass" may very well return a more sophisticated result, enabling a protected API in a session a bit similar to TLS.

Anders

On 2019-11-20 22:11, Smith, Ned wrote:
> *From: *RATS <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
> *Date: *Tuesday, November 19, 2019 at 6:00 PM
> *To: *Laurence Lundblade <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Rats] Two types of secure attestation
>
> Hi Laurence,
>
> On Tue, Nov 19, 2019 at 8:07 PM Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Kathleen,
>
>         On Nov 19, 2019, at 10:35 PM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Laurence,
>
>         On Tue, Nov 19, 2019 at 8:26 AM Laurence Lundblade <[email-masked] <mailto:lgl@island-resort..com>> wrote:
>
>             ·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
>
>             oTPM 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
>
>             oHashes fed into the TPM
>             oTPM 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)
>
>             oVerifier is complex
>
>             ·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
>
>             oBoot ROM verifies the SW that is loaded, particular the top privilege (e.g. kernel) SW
>
>             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
>
>             oHas a HW block that prevents access to the attestation key unless authenticated boot succeeds
>
>             oOnly top privilege SW can use it
>
>             ·Attestations are created in the top-privilege SW
>
>             oSimply signing a nonce proves the device is running approved SW
>
>             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
>

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 21 Nov 2019 04:33:49 +0000

The TUDA draft might satisfy session attestation semantics. There may be others.

From: Anders Rundgren <[email-masked]>
Date: Wednesday, November 20, 2019 at 8:11 PM
To: "Smith, Ned" <[email-masked]>, Kathleen Moriarty <[email-masked]>, Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Two types of secure attestation

Anders

From: RATS <[email-masked]><mailto:[email-masked]> on behalf of Kathleen Moriarty <[email-masked]><mailto:[email-masked]>
Date: Tuesday, November 19, 2019 at 6:00 PM
To: Laurence Lundblade <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [Rats] Two types of secure attestation

Hi Laurence,

Thanks,
Kathleen

LL

Hi Laurence,

Thanks,
Kathleen

TPM based
§  Has an attestation signing key for signing measurements that is kept secret by the TPM

Authenticated Boot based

LL

--

Best regards,
Kathleen

--

Best regards,
Kathleen

RATS mailing list

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 21 Nov 2019 06:02:55 +0100

> The TUDA draft might satisfy session attestation semantics. There may be others.

Thanx Ned,

I took a peek in
https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/
and I had a hard time finding similarities.

Session based attestation is not targeting constrained devices but rather powerful environments like mobile phones.
The multi-step "Protected API" and transactional operation is the core.  The session time is typically limited to 10 minutes.

Although it wasn't considered, TEEP could have been a candidate for this scheme as well:
https://cyberphone.github.io/doc/research/unified-tee-management-api.pdf

Anders

> 
> *From: *Anders Rundgren <[email-masked]>
> *Date: *Wednesday, November 20, 2019 at 8:11 PM
> *To: *"Smith, Ned" <[email-masked]>, Kathleen Moriarty <[email-masked]>, Laurence Lundblade <[email-masked]>
>     *From: *RATS <[email-masked]> <mailto:[email-masked]> on behalf of Kathleen Moriarty <[email-masked]> <mailto:[email-masked]>
>     *To: *Laurence Lundblade <[email-masked]> <mailto:[email-masked]>
>     *Cc: *"[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>                 §Has an attestation signing key for signing measurements that is kept secret by the TPM
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 21 Nov 2019 14:14:26 +0800

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 <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 21 Nov 2019 07:50:07 +0100

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.
> 
>   * 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 <[email-masked] 
>> <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> on 
>> behalf of Kathleen Moriarty <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date:*Tuesday, November 19, 2019 at 6:00 PM
>> *To:*Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>
>> *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 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi Kathleen,
>>> 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.
>>> 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.
>>>> On Nov 19, 2019, at 10:35 PM, Kathleen Moriarty 
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>> Hi Laurence,
>>>> 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 
>>>> <[email-masked] <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*
>>>>> [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.
>>>>> [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
>>>>> [nms] Verification implies the ability to determine boot code 
>>>>> integrity. This is common to platforms that use a TPM.
>>>>> [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.
>>>>> [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.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 21 Nov 2019 15:11:05 +0800

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 <[email-masked]> 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:
> 
>>> On Nov 21, 2019, at 5:11 AM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> *From:*RATS <[email-masked] <mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>
>>> *To:*Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>>> *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 21 Nov 2019 08:22:45 +0100

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 21 Nov 2019 16:06:43 +0800

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 <[email-masked]> 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.
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 21 Nov 2019 10:08:12 +0100

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.
> 
> 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 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Laurence,
>>
>> process (the thing the Verifier does) depends on what you want to 
>> verify and how complex the evidence and the Attester are.
>>
>> the more complex is the appraisal process. This is true for every RATS 
>> - TPM, fTPM or other TEE.
>>
>>> 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 
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> 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.
>>>>
>>>> The fundamental discrepancy I see is the differentiation between 
>>>> "TPM based" and "Authenticated Boot based", because:
>>>>
>>>>> 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.
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> 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).
>>>>>> 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 <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>> on behalf of Kathleen Moriarty 
>>>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>> *Cc:*"[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>" 
>>>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>> opposed to what you stated in your follow on email, which better 
>>>>>> maps to the restricted set in your first message.
>>>>>> Thanks,
>>>>>> Kathleen
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>> Hi Kathleen,
>>>>>>> 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.
>>>>>>> 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.
>>>>>>>> <mailto:[email-masked]> 
>>>>>>>> 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
>>>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>>>> <mailto:lgl@island-resort..com>> wrote:
>>>>>>>>> verifier comes to know that a device / entity is running 
>>>>>>>>> approved SW and will behave as desired.
>>>>>>>>> *TPM based*
>>>>>>>>> [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] 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.
>>>>>>>>> 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.
>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 21 Nov 2019 11:17:47 +0100

I re-read this as it made really no sense to me. I realize that I 
actually do not understand this sentence:

> 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…

What is "this part of the boot ROM" and why should anything in the boot 
ROM be called "verifier". It seems that it has occurred already. Could 
someone please tell me where and why? Was it mentioned on this list?

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 21 Nov 2019 16:52:57 +0000

I think this is a case where the verifier role is combined with the attester role such that an implicit attestation is all that is required by a remote verifier to arrive at a conclusion that the detailed policies applied by the verification logic in the boot code were applied. In other words, the system couldn't have booted incorrectly if it is able to supply implicit attestation to the remote verifier. 

On 11/21/19, 2:18 AM, "Henk Birkholz" <[email-masked]> wrote:

    
    
    Viele Grüße,
    
    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 22 Nov 2019 08:55:15 +0800

Agree with Ned’s characterization of the system behavior. 

However I think calling this a RATS verifier + RATS attester is very confusing. A RATS verifier consumes RATS format attestation evidence. It will often produces RATS format attestation results.

This part of the boot ROM usually uses highly propriety formats for signed operating system code, nothing that looks like COSE, CBOR or CoSWID. It might look like ELF. Maybe the TCG has some standards in this area, but I think it is far outside the RATS charter. 

I’ve had some exposure to commercial work on that sort of boot ROM code. It is the some of most cared-for, sacred and tested code in existance.

LL

> On Nov 22, 2019, at 12:52 AM, Smith, Ned <[email-masked]> wrote:
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 22 Nov 2019 09:03:04 +0800

> On Nov 21, 2019, at 5:08 PM, Henk Birkholz <[email-masked]> wrote:
> 
> 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?

You cannot create an EAT unless the authenticated boot was successful. The key material with which to sign the EAT is inaccessible if authenticated boot fails (or else the device just won’t boot at all).

This is the point of this whole discussion. :-)

> 
> How do you know that the boot state was not tempered with and the device is "lying" to you?

It is the same as knowing a TPM was not tampered with. 

The HW + boot ROM are built to a level of HW tamper resistance that is acceptable for the use case. 

> 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?

Yes

LL

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 22 Nov 2019 03:26:28 +0100

Hi Laurence,

okay - understood! The TPM based RATS in this scenario is covered by 
using a constrained Signing Key inside the TPM.

In essence, Section 4.12.1.1 of the "Trusted Attestation Protocol (TAP) 
Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0" defines:
"Implicit attestation is created when a signature is signed with a 
signing key(described in section 4.4), but with the additional 
requirement that the signing key can provably only be used to sign when 
the system is in a particular state. Thus,the very act of signing using 
that key proves the system is in that known state.If the data signed 
includes a nonce, then this proves the system was in that state after 
the nonce was provided.".

There are no semantic difference between the "simple non-TPM EAT" 
scenario and the TPM-based implicit remote attestation scenario. They 
are if fact the "same types of secure attestation".

Viele Grüße,

Henk

On 22.11.19 02:03, Laurence Lundblade wrote:
> 
>> On Nov 21, 2019, at 5:08 PM, Henk Birkholz 
> You cannot create an EAT unless the authenticated boot was successful. 
> The key material with which to sign the EAT is inaccessible if 
> authenticated boot fails (or else the device just won’t boot at all).
> 
>> 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?
> 
> Yes
> 
> LL
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 23 Nov 2019 08:44:06 -0800

> On Nov 21, 2019, at 6:26 PM, Henk Birkholz <[email-masked]> wrote:
> 
> There are no semantic difference between the "simple non-TPM EAT" scenario and the TPM-based implicit remote attestation scenario. They are if fact the "same types of secure attestation”.

I don’t have any need to drive taxonomic distinction when unnecessary, but note that the YANG module has to have explicit different facilities to be able to handle both.

The verifier implementations for these two types are also very different. in the "non-TPM EAT” scenario no known-good-values for SW hashes are need to be supplied to the verifier.

I don’t think these are the only differences that we’ll encounter in real implementations. 

This should probably all be described the architecture document. Seems as significant as the passport vs background check distinction.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Sat, 23 Nov 2019 19:20:01 +0000

@laurence - By “this” you mean the difference between implicit and explicit attestation?

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Saturday, November 23, 2019 at 8:44 AM
To: Henk Berkholz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Kathleen Moriarty <[email-masked]>, "Smith, Ned" <[email-masked]>
Subject: Re: [Rats] Two types of secure attestation

On Nov 21, 2019, at 6:26 PM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 23 Nov 2019 14:34:56 -0800

Hi Ned, (we missed seeing you in person)

Primarily the difference between TPM-style that doesn’t rely on secure boot and non-TPM-style that does rely on secure boot. 

You can and will implicit claims in either.

TPM-style is not going to have explicit claims unless you do TPM + EAT style. (Hmmm, should that be in the architecture and the YANG module?)

Makes sense, right?

LL

> On Nov 23, 2019, at 11:20 AM, Smith, Ned <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: Henk Berkholz <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] <mailto:[email-masked]>>
>> On Nov 21, 2019, at 6:26 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 24 Nov 2019 16:31:06 +0100

Hi all,

in a nutshell, one of the things I tried to express is that the 
following quite is simply not correct wrt to what is called here the 
"TPM-style" (I would really like to not use the words "TPM-style" and 
not to mixing authenticated & secure boot. Authenticated Boot is fine):
  > Primarily the difference between TPM-style that doesn’t rely on 
secure boot and non-TPM-style that does rely on secure boot.

It is never possible to create TPM structures that are signed 
Attestation Evidence, if a device that is explicitly intended to conduct 
"secure boot" did actually not do so successfully. That is one of the 
key-features of TPM/TSS remote attestation procedures.

On the other hand, what leaves me puzzled is the following. If these 
three quotes are all correct...

draft-ietf-rats-eat-01:

> All claims are optional

and draft-ietf-rats-eat-01 again:

> 3.7.  Secure Boot and Debug Enable State Claims (boot_state)
> 
>    This claim is an array of five Boolean values indicating the boot and
>    debug state of the entity.

... one is allowed either to omit that Claim in an EAT or set some 
values of the Claim members to false. Therefore indicating that the boot 
state is, e.g. "secure_boot_enabled=> false", and still be able to 
create the EAT. Is that correct? If not, why include this member of the 
boot_state Claim at all? It always made me think until now that it 
allows for a device to not conduct "secure boot" and still be able to 
create an EAT.

Besides that, what I think we are actually talking about is implicit and 
explicit attestation.

The "non-TPM-style" RATS Laurence is talking about seem to be implicit 
remote attestation and that if of course of "equal stature" to the 
implicit remote attestation that uses a TPM. I am not arguing with that 
- I am agreeing with that! :)

Viele Grüße,

Henk

On 23.11.19 20:20, Smith, Ned wrote:
> *From: *RATS <[email-masked]> on behalf of Laurence Lundblade 
> <[email-masked]>
> *Date: *Saturday, November 23, 2019 at 8:44 AM
> *To: *Henk Berkholz <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Kathleen Moriarty 
> <[email-masked]>, "Smith, Ned" <[email-masked]>
>     On Nov 21, 2019, at 6:26 PM, Henk Birkholz
>     scenario and the TPM-based implicit remote attestation scenario.
>     They are if fact the "same types of secure attestation”.
> 
> I don’t have any need to drive taxonomic distinction when unnecessary, 
> but note that the YANG module has to have explicit different facilities 
> to be able to handle both.
> 
> The verifier implementations for these two types are also very 
> different. in the "non-TPM EAT” scenario no known-good-values for SW 
> hashes are need to be supplied to the verifier.
> 
> This should probably all be described the architecture document. Seems 
> as significant as the passport vs background check distinction.
> 
> LL
> 
> 
> 
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 24 Nov 2019 12:01:26 -0800

> On Nov 24, 2019, at 7:31 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
> 
> in a nutshell, one of the things I tried to express is that the following quite is simply not correct wrt to what is called here the "TPM-style" (I would really like to not use the words "TPM-style" and not to mixing authenticated & secure boot. Authenticated Boot is fine):

It’s hard to know what to call things. I’m learning the “TCG language” slowly and we’re also evolving (in the architecture document) a common language. I keep trying terms and definitions to see what sticks and what doesn’t. Pretty sure we agree on “attestation evidence”, “verifier” and “attestation result”, but I don’t know what “secure boot”, “authenticated boot” and “trusted boot” mean to you so I don’t know which term to use.

> 
> It is never possible to create TPM structures that are signed Attestation Evidence, if a device that is explicitly intended to conduct "secure boot" did actually not do so successfully. That is one of the key-features of TPM/TSS remote attestation procedures.

It seems to me that TPM-style attestation where you measure each step in the boot sequence and report to a verifier was designed to work without secure boot. However I can see that it could also work with secure / trusted / authenticated boot.

> 
> On the other hand, what leaves me puzzled is the following. If these three quotes are all correct...
> 
> ... one is allowed either to omit that Claim in an EAT or set some values of the Claim members to false. Therefore indicating that the boot state is, e.g. "secure_boot_enabled=> false", and still be able to create the EAT. Is that correct? If not, why include this member of the boot_state Claim at all? It always made me think until now that it allows for a device to not conduct "secure boot" and still be able to create an EAT.

Yes, you are right that in some cases it would make no sense to have the secure boot claim. It is basically an implicit claim. Here’s some where it does make sense to have an explicit secure boot claim.

The main attester might boot securely, but submods might not.

It is possible to build pure HW that implements EAT attestation. It might be a part of a SoC. That attestation HW doesn’t use the main CPU to implement the attester, but can report on how the main CPU booted.

> 
> Besides that, what I think we are actually talking about is implicit and explicit attestation.

Seems like you have to say which claims are implicit and which claims are explicit and in many attestations you need and get both.

For example, you called out a situation where the secure boot claim is implicit and questioned the need for the claim. I then called out a situation where the secure boot claim is explicit. 

In one attestation the secure boot claim might be implicit and the GPS location is explicit.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 24 Nov 2019 23:22:43 +0100

Hi Laurence,

I am a bit time constrained right now, but I think we mostly agree.

Thank you for you explanation about the boot_state Claim - it was really 
hard to wrap my mind around that. Is it okay to raise an issue that this 
concept might require more explanatory text in the EAT I-D?

I'll compose some text about the horrible yet remediateable confusion 
that is the "“secure boot”, “authenticated boot” and “trusted boot”, 
etc. pp scope. Maybe I'll do it with Monty, if he finds the time for 
that in the very near future.

I am very happy that we already agreed on Attestation Evidence, 
Attestation Result, (maybe) Appraisal Policy (formerly known as 
Reference Values), Endorsements & the roles Attester, Endorser (formerly 
known as Asserter), Verifier and Relying Party. There was significant 
progress at the last IETF meeting. Without Ned, Dave, Michael, Thomas & 
you this would not have been such a productive meeting.

Viele Grüße from Manchester,

Henk

On 24.11.19 21:01, Laurence Lundblade wrote:
> 
> 
>> On Nov 24, 2019, at 7:31 AM, Henk Birkholz 
> It’s hard to know what to call things. I’m learning the “TCG language” 
> slowly and we’re also evolving (in the architecture document) a common 
> language. I keep trying terms and definitions to see what sticks and 
> what doesn’t. Pretty sure we agree on “attestation evidence”, “verifier” 
> and “attestation result”, but I don’t know what “secure boot”, 
> “authenticated boot” and “trusted boot” mean to you so I don’t know 
> which term to use.
> 
>>
>> Attestation Evidence, if a device that is explicitly intended to 
>> conduct "secure boot" did actually not do so successfully. That is one 
>> of the key-features of TPM/TSS remote attestation procedures.
> 
> It seems to me that TPM-style attestation where you measure each step in 
> the boot sequence and report to a verifier was designed to work without 
> secure boot. However I can see that it could also work with secure / 
> trusted / authenticated boot.
> 
> 
>>
>>> You cannot create an EAT unless the authenticated boot was 
>>> successful. The key material with which to sign the EAT is 
>>> inaccessible if authenticated boot fails (or else the device just 
>>> won’t boot at all).
>>
>> draft-ietf-rats-eat-01:
>>
>>> All claims are optional
>>
>> values of the Claim members to false. Therefore indicating that the 
>> boot state is, e.g. "secure_boot_enabled=> false", and still be able 
>> to create the EAT. Is that correct? If not, why include this member of 
>> the boot_state Claim at all? It always made me think until now that it 
> Yes, you are right that in some cases it would make no sense to have the 
> secure boot claim. It is basically an implicit claim. Here’s some where 
> it does make sense to have an explicit secure boot claim.
> 
>     It is possible to build pure HW that implements EAT attestation. It
>     might be a part of a SoC. That attestation HW doesn’t use the main
>     CPU to implement the attester, but can report on how the main CPU
>     booted.
> 
> 
> 
>>
> Seems like you have to say which claims are implicit and which claims 
> are explicit and in many attestations you need and get both.
> 
> For example, you called out a situation where the secure boot claim is 
> implicit and questioned the need for the claim. I then called out a 
> situation where the secure boot claim is explicit.
>

---

From: Monty Wiseman <[email-masked]>
Date: Wed, 27 Nov 2019 15:11:54 -0500

Let's not use confusing terms like TPM-style / TCG language. I propose
we start with lower-level fundamental definitions or even axioms for
boot types. Within those definitions, I recommend deprecating the term
"Secure Boot" as it's imprecise and even misleading. I expect there to
be variations on these creating derivative definitions but I postulate
these are fundamental as basic building blocks.

Root of Trust: Something that is assumed to always operate in the
expected manner. The implementation is assumed to be correct. How it is
implemented it outside the scope of its definition.

Verified Boot: Starts with a Root of Trust. For this type of boot the
Root of Trust is the Root of Trust for Verification (RTV). The RTV
includes a boot policy which is likely a verification key. The RTV
enforces the boot policy which continues through the boot process
assuming each component continues enforcing the boot policy or other
policies authorized by the RTV's boot policy. The trust in the device
depends on the RTV's boot policy and not on any external entity such as a
Verifier. The boot policy is locked by the RTV and cannot be further
evaluated beyond a binary "Trusted" or "Not Trusted" state. The evidence
of whether this device is trusted is, therefore, determined by whether
it boot to the correct state. (Some would say this is "existential boot.)

The TPM has no dependency on Verified Boot and Verified boot has no
architectural dependence on the TPM.

Measured Boot: Starts with the Root of Trust. For this type of boot it
is the Root of Trust for Measurement (RTM). The RTM contains no boot
policy. The device's components are recorded and stored through the boot
process as each component is assumed to continue measurement process. At
some time during the boot process these measurements are converted to
evidence and send to a Verifier. The trust in the device depends on a
Verifier's evaluation of this evidence. The Verifier has a rich set of
policy options available it beyond a binary "Trusted" or "Not Trusted"
state. The type of boot depends on a trusted component (such as a TPM)
record and converted the measurements into evidence.

Summary:
The difference between Verified Boot and Measured boot is where the
policy is enforced.

Verified Boot:
       1> Policy is hard coded at boot time, is immutable, and binary.
       (This form of boot is "existential" -- The device either boots to
       a valid state, or not)

       2> Is simpler to implement but less flexible

Measured Boot:
       1> The trust state is determined by a Verifier using evidence
       about the device and a flexible set of policies.

       2> Is more complex to implement but more flexible.

Diagram:

Verified Boot===>

     Policy

     |

     V

     RTV --- Component --- Component --- Component --- End State:

     A trusted device state is created only if all policies were met
     (i.e, the device booted). If any policy was not met, the device (as
     it is expected) doesn't really exist (it appears as a different
     device)

Measured Boot===>

Policy

                                                                |

                                                                V

     RTM --- Component --- Component --- Component --- End State:

    Trust State determined by a Verifier by appraising evidence collected
    using a set of policies.

Monty

Disclaimer: This is my personal opinion and not that of my employeer or
the Trusted Ccomputing Group. While I co-chair TCG's Trusted Network
Connect and Infrastructure Working Groups, the above defintions have
not been officially adopted by the TCG's Technical Committee or Board of
Directors.

On 11/24/19 3:01 PM, Laurence Lundblade wrote:
> what doesn’t. Pretty sure we agree on “attestation evidence”, 
> “verifier” and “attestation result”, but I don’t know what “secure 
> boot”, “authenticated boot” and “trusted boot” mean to you so I don’t 
> know which term to use.
>
>>
>> conduct "secure boot" did actually not do so successfully. That is 
>> one of the key-features of TPM/TSS remote attestation procedures.
>
> It seems to me that TPM-style attestation where you measure each step 
> in the boot sequence and report to a verifier was designed to work 
> without secure boot. However I can see that it could also work with 
> secure / trusted / authenticated boot.
>
>
>>
>> to create the EAT. Is that correct? If not, why include this member 
>> of the boot_state Claim at all? It always made me think until now 
>> that it allows for a device to not conduct "secure boot" and still be 
>> able to create an EAT.
>
> Yes, you are right that in some cases it would make no sense to have 
> the secure boot claim. It is basically an implicit claim. Here’s some 
> where it does make sense to have an explicit secure boot claim.
>
>     It is possible to build pure HW that implements EAT attestation.
>     It might be a part of a SoC. That attestation HW doesn’t use the
>     main CPU to implement the attester, but can report on how the main
>     CPU booted.
>
>
>
>>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 29 Nov 2019 14:09:54 -0800

That is really helpful, Monty. Thank you!

My understanding is that TPM-based remote attestation is all about sending the Measured Boot result to a server / service that is the verifier + relying party. That is what the Yang module draft, before EAT was added, is about, what Guy’s RIV drafts is about, and Franke pub-sub draft is about. 

My understanding is that Verified Boot is not directly relevant to the these just-mentioned IETF drafts. Devices doing remote Measured Boot might have used Verified Boot or might not have. It doesn’t matter. The remote server / service doesn’t know. It is not reported to them in the remote attestation.

In this regard, EAT is in a way the opposite. For SW-based implementations of EAT, Verified Boot is critical. The EAT is of little value without it. The server / service trusts an EAT because the manufacturer committed to not putting EAT signing keys into devices that don’t implement Verified Boot.

Does this line up with how you understand it?

LL

> On Nov 27, 2019, at 12:11 PM, Monty Wiseman <[email-masked]> wrote:
> 
>>> On Nov 24, 2019, at 7:31 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi all,
>>>