Subject: [Rats] some observations about the AR4SI document

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Mar 2022 09:34:48 -0500

Thomas Fossati <[email-masked]> wrote:
    > It's maybe worth looking at Section 2.2 of AR4SI where all of this is
    > discussed in depth.

I read it all.
(I remember this document now)

I guess that I'm surprised that 2.2.1 has to create the three categories
(HSM, Process, VM).  I couldn't figure out where this distinction turns up
later on.

Section 2.3.4 was very detailed about claim values.
I guess there is more work to even out the level of detail in the document.

I think that the goal is to detail a series of claims (keys and values) that
Verifiers would assert?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Mar 2022 19:43:32 +0000

Hi Michael,

> From: Michael Richardson, March 2, 2022 9:35 AM
> 
> 
> I guess that I'm surprised that 2.2.1 has to create the three categories (HSM,
> Process, VM).  I couldn't figure out where this distinction turns up later on.

The initial reason for the creation was to differentiate Attesting Environment types so that you know what specific identities and trustworthiness claims might actually be relevant. The identity mapping is what is shown in Table 1.   The Trustworthiness Claim mappings are in appendices A.1, A.2, & A.3

Some text here should change though. Just recently there has been work in the Confidential Compute Consortium (CCC) to define better categories than "Process" and "VM".  Once that settles, we should circle back to decide whether to adopt their categories.

> I guess there is more work to even out the level of detail in the document.

That was intentional as these are the normative claims which people will hopefully adopt into AR.  The sections before 2.3.4 is to understand how to use these Trustworthiness Levels.

> I think that the goal is to detail a series of claims (keys and values) that Verifiers
> would assert?

Actually just claims and values.  

The actual encoded structures are left to the implementer.  Guidance does exist however.  This guidance includes Section 3, as well as draft-voit-rats-trustworthy-path-routing.  Draft-voit provides a deployed example of the interconnectedness of Evidence, freshness, Attestation Results, and multiple identity signatures.

This interconnectedness is both crucial and subtle.  

Eric

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Mar 2022 17:15:34 -0500

> The initial reason for the creation was to differentiate Attesting
    > Environment types so that you know what specific identities and
    > trustworthiness claims might actually be relevant. The identity mapping
    > is what is shown in Table 1.   The Trustworthiness Claim mappings are
    > in appendices A.1, A.2, & A.3

Yes, but then what?  How do these categories affect anything?

It feels like you've just created a category of car, based upon the colour of
the hat the driver is wearing.  It has no affect on how well the car performs though.
Why does it matter?

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Mar 2022 23:09:24 +0000

> From: Michael Richardson, March 2, 2022 5:16 PM
> 
> (HSM,
> It feels like you've just created a category of car, based upon the colour of the
> hat the driver is wearing.  It has no affect on how well the car performs though.
> Why does it matter?

A few reasons:

(1) Not all Trustworthiness Claims are equally supportable by different hardware.  I.e., no matter how hard you try, a TPM isn't going to make your executables 'runtime-opaque'.   I.e., the type of Attesting Environment very much limits what can be meaningfully asserted.

(2) Some Trustworthiness Claims might be delivered implicitly.  E.g., keychain validation on the identity keys used to sign SGX Attestation Evidence will prove that something is running 'runtime-opaque'.  And when something is implicit, asserting a redundant explicit claim could itself prove problematic.

I.e., So the AE type categorization allows the RP to understand what claims might legitimately be asserted.

Eric

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Mar 2022 18:52:24 -0500

Eric Voit (evoit) <[email-masked]> wrote:
    > (1) Not all Trustworthiness Claims are equally supportable by different
    > hardware.  I.e., no matter how hard you try, a TPM isn't going to make
    > your executables 'runtime-opaque'.   I.e., the type of Attesting
    > Environment very much limits what can be meaningfully asserted.

Sure, but...

    > (2) Some Trustworthiness Claims might be delivered implicitly.  E.g.,
    > keychain validation on the identity keys used to sign SGX Attestation
    > Evidence will prove that something is running 'runtime-opaque'.  And
    > when something is implicit, asserting a redundant explicit claim could
    > itself prove problematic.

All of this sounds like policy that should arrive to the Verifier by
Appraisal Policy for Evidence.

    > claims might legitimately be asserted.

On the side of the RP, I still think that the RP just shouldn't care.
It might violate privacy.
If the RP can only work with something that is runtime-opaque, then the
Verifier should just say "NO".

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 3 Mar 2022 12:57:52 +0100

Hi Eric,

concise comments in-line.

Viele Grüße,

Henk

> (1) Not all Trustworthiness Claims are equally supportable by different hardware.  I.e., no matter how hard you try, a TPM isn't going to make your executables 'runtime-opaque'.   I.e., the type of…

yes, exactly that.

> (2) Some Trustworthiness Claims might be delivered implicitly.  E.g., keychain validation on the identity keys used to sign SGX Attestation Evidence will prove that something is running 'runtime-op…

As this work includes an IM for AR I think it is reasonable to assume 
that qualities represented in AR can be produced by the appraisal of 
Evidence conducted by a Verifier using corresponding Endorsements.
I.e., explicit identity of Attesting Environments in Evidence + 
Endorsement of identified Attesting Environments = *explicit* AR4SI 
Trustworthiness Claim (there are always more complex cases and also 
polices, of course - but that's the principle), right?

Viele Grüße,

Henk

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 3 Mar 2022 13:39:44 +0000

> From: Michael Richardson, March 2, 2022 6:52 PM
> 
> All of this sounds like policy that should arrive to the Verifier by Appraisal Policy
> for Evidence.

There are rules for determining the AR are in the Verifier.   The policy for what to do with the AR are in the RP.  Providing redundant info to the RP should be avoided where possible as it complicates policy design.
 
> If the RP can only work with something that is runtime-opaque, then the Verifier
> should just say "NO".

The ability to say "NO" assumes the Verifier knows who the RP is, and can tailor its responses accordingly.  (I.e., the background check model.)  With the passport model, AR are returned first to the Attester.  And the resulting AR can be shared to disparate types of RP.

Note: In deployments I care about, the background check model has scale, privacy, and latency drawbacks.  More thinking here is in ar4si section 3.1. 

Eric

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Mar 2022 13:57:11 -0500

Eric Voit (evoit) <[email-masked]> wrote:
    mcr> On the side of the RP, I still think that the RP just shouldn't care.
    mcr> It might violate privacy.
    mcr> If the RP can only work with something that is runtime-opaque, then the Verifier
    mcr> should just say "NO".

    > The ability to say "NO" assumes the Verifier knows who the RP is, and
    > can tailor its responses accordingly.  (I.e., the background check
    > model.)  With the passport model, AR are returned first to the
    > Attester.  And the resulting AR can be shared to disparate types of
    > RP.

You are saying that in the passport model, because the Verifier does not know
were the passport is going, the Verifier has to over-report in the AR.

You are also assuming that the same passport would be used with multiple RPs.

This like a recipe for disclosing PII inappropriately.

    > Note: In deployments I care about, the background check model has
    > scale, privacy, and latency drawbacks.  More thinking here is in ar4si
    > section 3.1.

I understand.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 3 Mar 2022 19:30:21 +0000

> From: Michael Richardson, March 3, 2022 1:57 PM
>
>     mcr> If the RP can only work with something that is runtime-opaque, then 
> the
> Verifier

Very much the opposite.  What goes to the AR is far smaller: much raw Evidence 
is never needed by the RP.  An example schema for a full set of RP provided 
info can be seen in draft-voit-rats-trustworthy-path-routing, Figure 5.

Using this passport model saves *all* the boot integrity Event logs entries 
from needing to be seen by the RP.  (I.e., this type of conveyance of Evidence 
hides what are potentially damaging event logs.)

> You are also assuming that the same passport would be used with multiple 

Yes.    Which means a single Attester might need to Verify itself 
infrequently.  Rather than a Verifier having to perform work for every time a 
new Relying Party is in the mix.

> This like a recipe for disclosing PII inappropriately.

Again I believe the opposite is the case.   If the RP chooses to trust the 
Verifier, then the RP needs a lot less Evidence from the Attester.   And all 
those proprietary boot logs (and the meanings of specific vulnerabilities) are 
hidden from the RP.

Hiding the log specifics likely is a legal necessity.  No Attester is going to 
risk telling another company's RP exactly what virus it got when.

Eric

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 3 Mar 2022 11:58:05 -0800

Hi Eric,

I haven’t got my head around what ar4si is trying to do with these environments yet, so maybe my comments are off in some ways.

I think attesters will be hosted by the full spectrum of HW, OS’s and SW possible. 
- purpose-built HW producing EATS or something similar. This is not a TPM. I know of chip project like this.
- Java/Swift running inside a phone app. 
- in IoT devices that don’t have an OS or file system
- written in Java on Secure Elements
- in subsystems like WiFi modules. 

Were you intending to cover all these for ar4si? The ar4si categorization doesn’t seem broad enough.

Here’s some comments on the three definitions (which I’ve copied from the draft).

>    1.  HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
>        which continually hashes security measurements in a way which
>        prevents an Attester from lying about measurements which have
>        been extended into the Attesting Environment (e.g., TPM2.0.)

No attesters should never lie and there’s no way to prevent an attester from lying when attacked, so I don’t think this distinction clarifies.

I’m not sure what continually hashing means. TPMs can only remember a hash input to them from the boot sequence. A product like Linux IMA can has the whole Linux OS memory space continually 24/7 (if you don’t mind the power drain).

The important characteristics of TPMS are 1) low attack surface, 2) defense against chip-level HW attacks, 3) certification.

> 
>    2.  Process-based: An individual process which has its runtime memory
>        encrypted by an Attesting Environment in a way that no other
>        processes can read and decrypt that memory (e.g., [SGX] or
>        [I-D.tschofenig-rats-psa-token].)

To me a “process” is more or less like a Linux process. It is an isolated executing thread in an operating system. That OS could be huge or small, certified or not. So “process" doesn’t tell me much about security.

I don’t think SGX or TrustZone are processes, though I understand SGX instances are associated with processes in the OS that makes use of them.

There are ways to strongly protect memory other than encryption. MMUs and MPUs for example are widely used for this in high security environments.

SGX always encrypts memory, but TrustZone does not.

If you are going after a limited execution environment, then its characteristics are 1) isolation from any associated high-level OS, 2) low attack surface, 3) security-oriented design

> 
>    3.  VM-based: An entire Guest VM (or a set of containers within a
>        host) have been encrypted as a walled-garden unit by an Attesting
>        Environment.  The result is that the host operating system cannot
>        read and decrypt what is executing within that VM (e.g., SEV or
>        TDX.)

Arm and Intel added instructions for VMs over the last decades. ARM has a thing called an SMMU that can virtualize the address space of HW blocks for SoCs. When you do virtualization in the cloud or on your PC or when there is isolation between subsystems on a smart phone, these instructions and/or SMMU is what is used. This mostly does not use memory encryption (the power and performance penalties would be unacceptable).

I think it is fine to use a VM to isolate an Attesting Environment to reduce its attack surface. When you do, you want to be sure that the OS running in the VM is a small security-oriented OS or you don’t gain anything.

I think of TrustZone as kind of special high-security VM. TrustZone uses memory protection HW, similar to a VM, to create an isolated environment were SW with a smaller attack surface can run.

To me a VM is more or less a limited execution environment. I’d say it’s main characteristic is 1) isolation from any associated high-level OS. 

LL

> On Mar 2, 2022, at 3:52 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 3 Mar 2022 20:43:16 +0000

Hi Laurence,

> From: Laurence Lundblade, March 3, 2022 2:58 PM

> I haven’t got my head around what ar4si is trying to do with these environments

> yet, so maybe my comments are off in some ways.

> - purpose-built HW producing EATS or something similar. This is not a TPM. I

> know of chip project like this.

> Were you intending to cover all these for ar4si? The ar4si categorization doesn’t

> seem broad enough.

The purpose of the hardware categorizations is to understand and provide guidance on what types of Trustworthiness Claims might legitimately be appraised.   This list could (and should) be augmented to support the environments above.  

> Here’s some comments on the three definitions (which I’ve copied from the

> draft).

> No attesters should never lie and there’s no way to prevent an attester from

> lying when attacked, so I don’t think this distinction clarifies.

Better text would be to detect lying rather than prevent lying.  I will push a text change to the GitHub repository.

> I’m not sure what continually hashing means. TPMs can only remember a hash

> input to them from the boot sequence. A product like Linux IMA can has the

> whole Linux OS memory space continually 24/7 (if you don’t mind the power

> drain).

> The important characteristics of TPMS are 1) low attack surface, 2) defense

> against chip-level HW attacks, 3) certification.

> To me a “process” is more or less like a Linux process. It is an isolated executing

> thread in an operating system. That OS could be huge or small, certified or not.

> So “process" doesn’t tell me much about security.

> I don’t think SGX or TrustZone are processes, though I understand SGX instances

> are associated with processes in the OS that makes use of them.

> There are ways to strongly protect memory other than encryption. MMUs and

> MPUs for example are widely used for this in high security environments.

> SGX always encrypts memory, but TrustZone does not.

As noted in earlier in the thread, there is a lot of new text coming from the Confidential Computing Consortium (CCC) here.  A preview of a bit of the taxonomy is here:

Once the CCC finalizes terms for memory isolation methodologies, I am hoping this document can simply adopt them.  I.e., we can eject the current definitions of process-based and VM-based which themselves originated in the CCC.

> If you are going after a limited execution environment, then its characteristics

> are 1) isolation from any associated high-level OS, 2) low attack surface, 3)

> security-oriented design

These characteristics are one way of cutting things.  The goal for the characterization needed in this section is to determine which Trustworthiness Claims can legitimately be asserted by a Verifier.  In this context 1) matters, but 2) & 3) do not.

Eric

> Arm and Intel added instructions for VMs over the last decades. ARM has a thing

> called an SMMU that can virtualize the address space of HW blocks for SoCs.

> When you do virtualization in the cloud or on your PC or when there is isolation

> between subsystems on a smart phone, these instructions and/or SMMU is what

> is used. This mostly does not use memory encryption (the power and

> performance penalties would be unacceptable).

> I think it is fine to use a VM to isolate an Attesting Environment to reduce its

> attack surface. When you do, you want to be sure that the OS running in the VM

> is a small security-oriented OS or you don’t gain anything.

> I think of TrustZone as kind of special high-security VM. TrustZone uses memory

> protection HW, similar to a VM, to create an isolated environment were SW

> with a smaller attack surface can run.

> To me a VM is more or less a limited execution environment. I’d say it’s main

> characteristic is 1) isolation from any associated high-level OS.

> > On Mar 2, 2022, at 3:52 PM, Michael Richardson < <mailto:[email-masked]> [email-masked]>

> wrote:

> > Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]> wrote:

> >> (1) Not all Trustworthiness Claims are equally supportable by

> >> different hardware.  I.e., no matter how hard you try, a TPM isn't going to

> make

> >> when something is implicit, asserting a redundant explicit claim

> >> could itself prove problematic.

> >> I.e., So the AE type categorization allows the RP to understand what

> >> claims might legitimately be asserted.

> > If the RP can only work with something that is runtime-opaque, then

> > the Verifier should just say "NO".

> > Michael Richardson < <mailto:[email-masked]> [email-masked]>   . o O ( IPv6 IøT consulting )

> >  <mailto:[email-masked]> [email-masked]

> >  <https://www.ietf.org/mailman/listinfo/rats> https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Mar 2022 16:13:50 -0500

> hides what are potentially damaging event logs.)

Well, there could be object encryption between Attester and Verifier, via the RP.

    > risk telling another company's RP exactly what virus it got when.

It's only fair when comparing Background check and Passport models, that the
channel from Attester to Verifier is private from all parties.

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 4 Mar 2022 00:40:12 +0000

(not as chair)
The RATS architecture anticipated that the Attester trusts the Verifier with possible PII not to collude with RPs. If unencrypted, any observer including the RP in a background check would obtain Attester PII.

If Verifier is trusted to handle Attester PII (and RPs are not) then claims containing PII have to be filtered (privacy protected / obfuscated) before becoming ARs. 

Attester identity used to authenticate the session between Attester : Verifier has privacy risk if identity credential uniquely identifies the Attester. Attester trusts Verifier not to collude with RP using identity credential. 

Alternatively, DAA is used as Attester identity credential which allows Attester to say "I'm a member of group Z" and "I have model X". Verifier doesn't have knowledge of which Attesters are in group Z therefore it can't collude with RP to deduce which Attesters specifically are in group Z or have model X. 

In a passport model, Verifier supplies a token saying "the bearer of this token has model X". The RP can validate the token and that the presenter of the token is the bearer. 

If the model X group is small - maybe only 3 were manufactured - then RP could reason about all transactions involving all three and deduce which is which. Same is true for group Z. If model X or group Z populations are large, then it becomes infeasible to reason about them (e.g., differential privacy analysis is inconclusive). Attester retains its privacy.

RP only cares about a policy that accepts model X and rejects model Y.

-Ned 

On 3/3/22, 1:14 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 13 Mar 2022 16:28:06 -0700

Below

> On Mar 3, 2022, at 12:43 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 

Incorrect Evidence arrives at the Verifier for one of these reasons:
  - Implementation mistake — unintentional by the maker
    - bug in the attester code — not a security vulnerability, a bug that produces the wrong measurement or OEM ID or such
    - error in the device manufacturing process — the wrong OEM ID is programmed in on the factor floor
  - A successful attack — intentional by attacker
    - on the manufacturing process — sabotage by an employee, ...
    - on the attester — side channel attack, found a bug in the attester code,...

I don’t think “lying” characterizes any of these

The preventions against incorrect evidence are:
   - choosing stronger (and more costly) defenses, particularly HW defenses, but also stronger crypto and many other things
   - SW and system design processes (SW life cycle)
   - Certification

Don’t think “lying prevention/detection” (truth serum?) characterizes any of these either.

“H” in “HSM” is for hardware. That makes me think the characteristic you are after is that the Attester defends against hardware attacks, but I’m not really sure.

If defense against HW attacks is what you after, then the description I’d choose is based on the EAT hardware security-level claim:

Entities at this level must include substantial defense against physical or electrical attacks against the entity itself.  The manufacturing process should be equivalently secured. It is assumed the potential attacker has captured the entity and can disassemble it.  Such attacks must be defended. Examples include TPMs and Secure Elements.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 14 Mar 2022 17:49:36 +0000

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Sunday, March 13, 2022 7:28 PM
To: Eric Voit (evoit) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Thomas Fossati <[email-masked]>; [email-masked]
Subject: Re: [Rats] some observations about the AR4SI document

Below

On Mar 3, 2022, at 12:43 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

<eric> agree that lying isn't the right word.  I changed the sentence to:

Maintenance of this hash enables detection of an Attester which is not reporting the exact set of security measurements (such as log entries) taken within the Attesting Environment.

   - Certification

<eric> I don't know what substantial defense means.  I don't know what equivalently secured means.  This is why I prefer the statement above which describes the purpose of the hashing.

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 14 Mar 2022 11:18:24 -0700

Hi Eric,

Hashing is one thing and HSM security is another.

You can have an attester that has HSM security and does no hashing. An example of this is a purpose-built HW that just provides identity.

You can have an attester that does lots of hashing of lots of things and isn’t an HSM in any sense. An example of this is an attester built into an operating system.

When I copied text from the security levels definition, it was all about hardware security, not hashing. I don’t think any sort of hashing in an attesters architecture can stand in for hardware security. (And the security levels text could probably be improved).

(You know what I mean about hardware security right? These are defenses against attacks on the HW. For example, extra electrical circuits that shutdown the chip if the supply voltage is too low to prevent manipulation of the supply voltage to get the hardware to execute incorrectly. There are lots of these.)

So I’m not sure what trying for in this definition. As I said, it would seem to be defense against HW attacks, but if that’s true then why bring up hashing? Hashing doesn’t help against attacks against the HW.

LL

> On Mar 14, 2022, at 10:49 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Laurence Lundblade
> To: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>>
> Cc: Michael Richardson <[email-masked] <mailto:[email-masked]>>; Thomas Fossati <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Mar 3, 2022, at 12:43 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 14 Mar 2022 21:04:15 +0000

Hi Laurence, 

From: Laurence Lundblade, March 14, 2022 2:18 PM

Hi Eric,

<eric> In my opinion, it is mandatory for the RATS WG to provide guidance on what AR claims might be legitimately be made about from different categories of Attesters.   The objective of ar4si section 2.2.1 is to differentiate categories of Attester.   I do accept your point that there are HSMs which don't do hashing.  This insight helps improve the document.  So I have just added a tracking issue with a suggestion to change the category name to "tpm-pcr-hashing".  

If you want to propose additional HSM types which generate non-hash based evidence, that would be helpful.   The intention/goal of a category should be to help restrict what AR claims might legitimately be made about an Attester.

<eric> Can you point to a definition for Hardware security?  While I know in general what it means, but you can't define just the term based on examples.  Nor can you define it with by saying "substantial defense".  What is needed are one or more sentences which says what is covered and what is not.

Eric  

LL

On Mar 14, 2022, at 10:49 AM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

From: RATS <[email-masked] <mailto:[email-masked]> > On Behalf Of Laurence Lundblade
Sent: Sunday, March 13, 2022 7:28 PM
To: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> >
Cc: Michael Richardson <[email-masked] <mailto:[email-masked]> >; Thomas Fossati <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Rats] some observations about the AR4SI document

Below

   - Certification

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 19 Mar 2022 09:20:05 +0100

Hi Eric,

> On Mar 14, 2022, at 10:04 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Laurence, 
>  
> <eric> In my opinion, it is mandatory for the RATS WG to provide guidance on what AR claims might be legitimately be made about from different categories of Attesters.   The objective of ar4si section 2.2.1 is to differentiate categories of Attester. 

OK. I understand that you want to build a taxonomic system for Attesters. Presumably it would be complete such that every Attester logically fits into the classification.

What is the basis of the taxonomy? One candidate is system architecture (HW and SW). Another is the amount of security provided. The three categories provided so far seem to go for both.

When I say system architecture I am thinking of the combination of HW and SW. Thinks like protected mode OS or not. Virtualization or not. Implementation of some or all of the functionality in pure HW. Use of interpreted languages like Java and Python versus native code. CPU or GPU or DSP.

RATS standard Attesters can be implemented using any and every system architecture in the known universe, so such a classification seems a pretty tall order.

The taxonomy could also be based on security provided. That is roughly equivalent to defining the EAT security-level claim.

It could be the product of architecture and security provided, but that is multiplicatively harder than one or the other.

A rigorous taxonomy in an IET standards doc seems difficult to create to me.

>  I do accept your point that there are HSMs which don't do hashing.  This insight helps improve the document.  So I have just added a tracking issue with a suggestion to change the category name to "tpm-pcr-hashing".  
>  

It kind of seems like you want the RP to know the Attester Category and cross-check that the Verifier is only providing trustworthiness claims appropriate for the Category.

This seems like a complication and burden for the RP, but more than that, I think an RP needs to evaluate a Verifier based on legal, reputation, SLA and business criteria, but once they’ve done that they pretty much trust all the bits they receive implicitly. 

There’s a huge number of ways a Verifier can perform incorrectly. They may be sloppy, underfunded and have dumb people. They may get bad input from an Endorser. They might have bugs in their code. The only way to address that is business and legal means that we don’t address here in the IETF.

I don’t see how a few cross-checks provided by the RP would do much considering all the other possible Verifier failures.

> <eric> Can you point to a definition for Hardware security?  While I know in general what it means, but you can't define just the term based on examples.  Nor can you define it with by saying "subs…

Agree my wording could be improved. This should be better, but probably can still be improved. I’m going reference the three FIDO levels described here <https://fidoalliance.org/certification/authenticator-certification-levels/>.

Hardware Security — FIDO L3 — Defend against HW-based local attacks
The attacker has physically captured the device and taken it back to their workshop (or maybe they have a mobile toolkit). The workshop might be a sophisticated laboratory or just equipped from Radio Shack. The attacks they attempt might start with hooking up test equipment to try to read out the keys or such. They might try to glitch the power supply or clock to get the Attester to execute incorrectly and reveal the key or other secret. They might try power consumption and RF emanation side channels. In a fancy lab they might fire a laser at an area of the chip to glitch execution or even use a focused ion beam to modify the chip.

An attester with HW-level security defends against some, many or maybe all of these attacks. There’s a big range of defenses possible. Some are expensive and slow down the CPU a lot. It’s hard to draw a bright line between the basic defenses and the strongest ones. FIDO tries by distinguishing L3 from L3+.

TPM’s and Secure Elements are in this range. SGX provides a little of this, but just a little.

FIDO L2 — Defend against remote attacks with smaller implementation
The attacker doesn’t have physical access. They are attacking protocols and the implementation remotely.  A perfect SW implementation would perfectly defend against this.

Since it is difficult to make perfect SW, we reduce the amount of SW that is needed to implement the Attester. This is the purpose of a TEE, SGX and virtualization. It reduces the attack surface.

Usually there is some HW support to isolate the more-trusted SW, but mostly this is just memory protection HW. A TEE is primarily memory protection HW. 

Since the amount of SW is smaller, it is possible to do certification on this SW with reasonable cost.

FIDO calls this a restricted operating environment ROE. See here <https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-allowed-restricted-operating-environments-list-v1.2-fd-20201102.html>.

FIDO L1 — Everything else

This is a high-level scheme that is a bit rough and subjective but useful. When you actually get the certification at these levels, it is based on many pages of written requirements.

The only system I know of that quantifies security on any solid footing is the Common Criteria Attack Potential Calculation. It scores defenses with a points system that has been carefully thought out. Look here <https://www.commoncriteriaportal.org/files/supdocs/CCDB-2009-03-001.pdf> at pages 21-23 to get an idea. FIDO uses this for L3 and L3+.

It is very expensive to score any individual implementation this way because it takes a thorough threat analysis. You can measure the voltage of a battery with a cheap voltmeter in seconds. To measure the security of an implementation it takes man months or even man years of paying very high-priced people to get a number but it is kind of possible to get a number.

LL