Re: [Rats] debug disable (was Re: Processing Endorsements and Evidence into Results)

[Dave Thaler <[e-mail]>]

“that’s not how debug for SW / apps usually works. There’s not usually config to turn debug on or off for individual apps.”

I can tell you that IS how it works for Intel processors, including apps that run in SGX enclaves.
So “usually” is perhaps a matter of perspective, or a matter that varies by chip vendor.

From: Laurence Lundblade <[e-mail]>
Sent: Friday, April 3, 2020 11:00 AM
To: Dave Thaler <[e-mail]>
Cc: Ned Smith <[e-mail]>; [e-mail]
Subject: debug disable (was Re: [Rats] Processing Endorsements and Evidence into Results)

The latest debug disable text is here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fblob%2Fmaster%2Fdraft-ietf-rats-eat.md&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822524667&sdata=Tq0ty5ZdUg2CEQbrqhxRs2lSy2FXPkS5ktpdXdmKvks%3D&reserved=0> in GitHub but not yet in a released draft.

The “permanent disable” state still allows for the OEM (and only the OEM) to enable for things like RMA so it couldn't go in an endorsement. “full permanent disable” could, but only if the manufacturer really did it for every chip they shipped.

The debug facilities the claim is aimed at are HW and system facilities like JTAG, scan chain, Arm Coresight<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.arm.com%2Fip-products%2Fsystem-ip%2Fcoresight-debug-and-trace&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822534662&sdata=VWtpD%2BT2BxIxdamCpIKesvGcezuiZ9Xn5NpZum76Is8%3D&reserved=0> and such.

Maybe for some app download systems it might make sense to make the app an Attestation Target and make claims about that app’s debug state, but that’s not how debug for SW / apps usually works. There’s not usually config to turn debug on or off for individual apps.

LL



On Apr 2, 2020, at 9:27 PM, Dave Thaler <dthaler=[e-mail]<mailto:dthaler=[e-mail]>> wrote:

Debug-disable is not (in general, but can be in specific cases) permanent for a device, it can vary by application on the same device,
and can vary over time as say software/firmware is patched or configured, so cannot in that case be in an endorsement.

Also I would expect that endorsements generally also carry some sort of expiration or validity period as well, which isn’t in Laurence’s example.
(And expiration time is an example of something that equality comparison against a “known good value” doesn’t work for.)

Dave

From: RATS <[e-mail]<mailto:[e-mail]>> On Behalf Of Smith, Ned
Sent: Thursday, April 2, 2020 9:20 PM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

BTW: Since ‘debug-disable’ is permanent it could probably equally be included in Endorsement.
It is also reasonable that Verifier could downgrade ‘security level’ based on other claims and how they relate to policies. Security level in Evidence is an assertion the attester makes that has to be substantiated in some way. It could also be used exclusively as a conclusion in Results based on review of a bunch of other claims (in other words Attestation Results cold acquire additional claims beyond what originally existed in the intersection of Evidence and Endorsement.

Policies and or standardized profiles decide all these variables IMHO.

But the example seems to be illustrative (if that was the intent).

-Ned

From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 2, 2020 at 4:16 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] Processing Endorsements and Evidence into Results

Let me make this much more concrete with an example. I’m using JSON representation of CWT/EAT/Endorsements with C-style comments for reading ease.

Endorsement
{
    “trust-evidence”: “all”,           // E0, I just made this up
    “field-upgradable”: true,          // E1, from draft-birkholz-rats-endorsement-eat-00
    “shielded-secret”: internal,       // E2, from draft-birkholz-rats-endorsement-eat-00
    “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822534662&sdata=nsZC6mvYV9zlP7uRNMHQfmJz0dQQV6rFIS4B6CzJ1DY%3D&reserved=0>”,      // E3, from draft-birkholz-rats-endorsement-eat-00
}

Evidence
{
    “iat": 5734873409823,              // C1 time stamp for evidence creation time(eg) from EAT draft
    “security-level”: 4                // C2 the security level is “hardware” from EAT draft
    “debug-disable”: “permanent”       // C3 debug is permanently disabled for all but the OEM from EAT draft
}

Results
{
    “field-upgradable”: true,          // R1, from draft-birkholz-rats-endorsement-eat-00
    “shielded-secret”: internal,       // R2, from draft-birkholz-rats-endorsement-eat-00
    “common-criteria”: https://www.commoncriteriaportal.org/files/epfiles/0879V3a_pdf.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.commoncriteriaportal.org%2Ffiles%2Fepfiles%2F0879V3a_pdf.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822544656&sdata=lsMPnL5msEN1uX2ou2%2FQtvfs9rO%2BjgAkESghd7fJDk8%3D&reserved=0>”,      // R3, from draft-birkholz-rats-endorsement-eat-00
    “iat": 5734873409823,              // R4 time stamp for evidence creation time(eg)
    “security-level”: 4                // R5 the security level is “hardware”
    “debug-disable”: “permanent”       // R6 debug is permanently disabled for all but the OEM
}

In this example, the RP is probably feeding this into a risk engine so they want all the details.


Here’s another very abbreviated example with made up claim names:

Endorsement (not showing any signing)
{
    “expected-hash”: “TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZW”
}

Evidence
{
    “actual-hash”: “TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZW"
}

Results
{
    “verified”: true,
}

This all seems like the eventual logical result of the EAT, endorsements and architecture drafts to me.

LL




On Apr 2, 2020, at 12:36 PM, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

Now that we have a first draft describing endorsements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822544656&sdata=SW8xIOOAErhMdjKuNsNgBARAZQmHfOAQ7HuolO2ekV4%3D&reserved=0>, and they look like Evidence and Results, it seems interesting to consider some of how the verifier uses Endorsements (reference the architecture diagram below).

Let’s say there are three things in the endorsement, E1, E2 and E3, three things in the evidence, C1, C2 and C3 and three in the results, R1, R2 and R3.

Then three simpleton top-level cases:

1) An Endorsement is passed through and becomes a result: E1 — > R1
2) A Claim is passed through and becomes a results: C1 —> R2
3) Some endorsements combine with some claims to become a result: {E2, E3, C2, C3} —> R3

However that seems to be too simple and I think there has to be some sort of a primitive endorsement, call it E0, whose semantics are that some or all of the claims can always be believed. I think that means 2) doesn’t really exist, but has to be this:

2) Some claims can pass through with the use of the primitive E0 endorsement: {E0, C1} —> R2

One way E0 could be defined in the draft describing endorsements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-birkholz-rats-endorsement-eat-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822554653&sdata=kidjLndIlonCynAiwdKXGgMg5bHAUKPYkXL%2BB2fpzE0%3D&reserved=0> is that it is a list of the labels of claims that are trusted to be passed through. For numeric labels  a range INT64_MAX to INT64_MIN (or -infinity to +infinity)  indicates all claims are trusted. It could also list specific ones that are trusted.

From the TEE, FIDO and Android Attestation views of the world where measurements aren’t a primary thing and secure/trusted boot is required and always on, a common model will be to pass everything through to create an aggregate result. It could be represented this way:

E1->R1
E2->R2
E3->R3
{E0,C1}->R4
{E0,C2}->R5
{E0,C3}->R6

I think this goes on to submodules too and has some relation to the attempted to propose a connection type.  Endorsements may be able to say how submodules are trusted. There might even be an E00 primitive that says the lead attester is allowed to say how submodules are trusted. This whole line of thinking was partly prompted by this issue<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fissues%2F58&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822554653&sdata=nam1GKA%2BNGc31Lubnb%2BsT2xqe9Ft9vDtw4v4JL%2BrWKg%3D&reserved=0> against EAT and comments from Giri and Dave.

LL



                 ************   ************    *****************

                 * Endorser *   * Verifier *    * Relying Party *

                 ************   *  Owner   *    *  Owner        *

                       |        ************    *****************

                       |              |                 |

           Endorsements|              |                 |

                       |              |Appraisal        |

                       |              |Policy for       |

                       |              |Evidence         | Appraisal

                       |              |                 | Policy for

                       |              |                 | Attestation

                       |              |                 |  Result

                       v              v                 |

                     ..-----------------.                |

              .----->|     Verifier    |------.         |

              |      '-----------------'      |         |

              |                               |         |

              |                    Attestation|         |

              |                    Results    |         |

              | Evidence                      |         |

              |                               |         |

              |                               v         v

        ..----------.                      ..-----------------.

        | Attester |                      | Relying Party   |

        '----------'                      '-----------------'







_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822564647&sdata=RR7tPQoY1JmQd5MEOCQyxxRs%2BpCkExAi0B%2BB53aSJhg%3D&reserved=0>

_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdthaler%40microsoft.com%7Ccc125ca1c90445f1433308d7d7f8da45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215336822564647&sdata=RR7tPQoY1JmQd5MEOCQyxxRs%2BpCkExAi0B%2BB53aSJhg%3D&reserved=0>