Subject: [Rats] When do you assign a new HW Class ID?

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Nov 2021 11:16:45 -0800

Assume the Attester in all of these is the TrustZone. Which of these examples have the same Class ID and which don’t?
NXP IoT chip using ARM Cortex-M33 with TrustZone. Version 2 of the NXP chip
NXP IoT chip using ARM Cortex-M33 with TrustZone. Version 3 of the NXP chip
NXP IoT chip using ARM Cortex-M35P with TrustZone version 1 (Assume an M35P is the same as an M33 with more tamper resistant HW, so SW compatible, but more secure)
ST Micro IoT chip using ARM Cortext-M33 with TrustZone
Qualcomm Snapdragon SoC using ARM A53 with TrustZone and 4G modem
Qualcomm Snapdragon SoC using ARM A53 with TrustZone and 5G modem
Samsung Exynos SoC using ARM A53 with TrustZone
Qualcomm Snapdragon SoC using ARM X1 with TrustZone
My guess is that the only ones that have the same class ID are the first 2. My understanding is that TEEP is aiming for fairly fine-grained differentiation.

Is it primarily about SW compatibility? 

Does increased tamper resistance warrant a new class ID, assuming exactly SW compatibility?

The answer to this question helps clarify what a Class ID identifies. Saying it is a UUID doesn’t tell you when to use the same UUID or a different one because according to the UUID specification they can be different every time they are generated (nonce), for each device instance (like a UEID), and so on.

LL

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Nov 2021 16:44:06 -0500

Laurence Lundblade <[email-masked]> wrote:
    > Assume the Attester in all of these is the TrustZone. Which of these
    > examples have the same Class ID and which don’t?

Seems like a detailed operational question to me.
I understand you are looking to write guidance, but sometimes one can't do
that until it's impacted with reality.  That's why the difference between
Proposed Standard and Internet Standard :-)

    > exactly SW compatibility?

It would depend upon whether the better tamper resistance allows for a
different software.

    > The answer to this question helps clarify what a Class ID
    > identifies. Saying it is a UUID doesn’t tell you when to use the same
    > UUID or a different one because according to the UUID specification
    > they can be different every time they are generated (nonce), for each
    > device instance (like a UEID), and so on.

I think that it's best to give every hardware class it's own ID, and then, in
the Endorsements, to be able to provide a list of compliant classes.

The hardware manufacturer doesn't get to blur which hardware is out there.
Similiarly, the software guys don't get to lock to a single UUID, because
that breaks upwards compatibility: they have to trust the Verifier to do it's work.

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