Re: [Rats] [Teep] Class ID claim (and other HW identification)

[Brendan Moran <[e-mail]>]

Hi Lawrence,

I don’t think I was clear. I was saying that class IDs are important, but that there’s no need to differentiate between /types of classes/. When class IDs are opaque blobs, a lookup of some sort is implied. Since a lookup is being done, the /type of class/ should be extracted in the lookup. There’s no need to differentiate between types of classes in EAT itself since it’s for transporting information that will later have a lookup done.

Best Regards,
Brendan

On 11 Jan 2022, at 04:33, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

Hey Brendan,

I made the HW-IP PR as an educated guess, from talking to Dave, and from a some text in section 7 of TEEP Architecture. I don’t have any agenda here but to make EAT work well for SUIT and TEEP.

Obviously, I’m missing the mark, so I’m graciously bowing out. So no class ID in the EAT draft.

LL


P.S. I do appreciate the discussion as is resulted in adding the HW Model ID claim to EAT, something that was missing.


On Jan 10, 2022, at 1:12 PM, Brendan Moran <[e-mail]<mailto:[e-mail]>> wrote:

IMO, adding a new claim like this is counterproductive. It presupposes that we can predict all classes that a device may belong to. Sure, we can make a registry of different kinds of classes that a device can belong to, but why? Frankly, the naive approach is better than this: you have a database that maps OEM + model + revision into an application-specific taxonomy. Of course, now someone has to actually maintain that database. Have fun.

Why not take the easy route? It’s far simpler for a device to be the intersection of ANY properties that make it distinct. The entity consuming an EAT needs those anyway. And as to why I don’t want a taxonomy? Because it’s unnecessary. To use any of these identifiers, you have to use a database to convert the identifier into whatever it is that you actually care about. That database can just as easily contain any taxonomy you like.

We’re talking about adding more complexity to a specification in order to distinguish between:

SELECT * FROM hw_ip_identifiers WHERE id=${ID}
Vs
SELECT * FROM hw_identifiers WHERE id=${ID} AND taxonomy=“hwip"

Why would we complicate the spec to add taxonomies in order to simplify a database in such a trivial way?

In my opinion, we should look at a single physical device as the intersection of several sets:
* the OEM’s model identifier (incl. HW revision)
* the SoC identifier (incl. SoC revision)
* the processor’s type/version/revision
* the trusted OS’s version/revision
* the boot loader (especially if it’s in ROM) version/revision.

All of these matter (I think) to TEEP. We need to report them all. But is the list exhaustive? Probably not. While a registry for the different taxonomies may be relevant, I doubt it matters in EAT itself. That only matters when looking up an identifier.

What is the concrete value of specifying the taxonomy of an opaque blob in an interchange document?

Thanks,
Brendan





On 7 Jan 2022, at 23:56, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

So rather than a HW Class, how about a HW IP claim? It would reuse the same triple for identifying HW, OEM, Model, Version. It could occur along side the HW OEM, model and version. This seems better than my current PR and lines up better with Brendan’s examples and with the reality that HW IP comes from a vendor, has models and versions. I’ll write up a PR for it if I receive some positive feedback here.


The distinction between chip and device is intended to be handled by submodules in EAT. Submodules can express arbitrarily complex architectures and device compositions.

I think it’s cleaner to keep the HW-identifying claims separate from the SW-identify claims. Would really like the identification of the Trusted OS Vendor be handled by CoSWID and friends. Trying to make some claim suitable for identifying both SW and HW for all of attestation seems over-ambitious.

I also think it’s fine to define some claims better suited to the TEE world in TEEP if we can’t find enough common ground between TEEP and the very broadly applicable stuff that goes into EAT.

LL


Note: I find the use of the word “class” here confusing. If I were putting TV’s into classes I’d uses classes like smart/dumb, display type (LCD, CRT, OLED) and such that identify characteristics of TVs independent of vendor and model. "Sony Bravia" is not a class IMO. Nor is “Microsoft Windows” (an OS the runs on lots of HW platforms). I’d like to move away from the word.



On Jan 4, 2022, at 3:06 AM, Brendan Moran <[e-mail]<mailto:[e-mail]>> wrote:

I think devices will need to report multiple vendor/class pairs.

For example, A mobile device could potentially contain:
1. A Mobile Device OEM Vendor ID
2. A Silicon vendor’s Vendor ID
3. An IP vendor’s Vendor ID

This is not an exhaustive list.

For Arm Trust Zone TEEs, I would expect to see:
1. The Arm Vendor ID + the processor core’s Class ID
2. The Trusted OS Vendor ID + the Trusted OS Class ID
3. The Silicon vendor’s Vendor ID + the processor Class ID
4. The Device OEM’s Vendor ID + the device Class ID

Cheers,
Brendan

On 3 Jan 2022, at 21:00, Dave Thaler <dthaler=[e-mail]<mailto:dthaler=[e-mail]>> wrote:

Laurence Lundblade wrote:
I talked to Dave which resulted in reorientation of my understanding of Class ID in TEEP.

Class ID basically identifies HW IP from a HW designer like Arm or Synopsis that is integrated into chips made by various HW OEMs like Qualcomm, Samsung and Apple. The term used frequently for this is "IP" (I know this well from my days working on HW at Qualcomm).

I've created a PR for HW Class.

Since what is identified spans OEMs, this must be a globally unique identifier. We need to be explicit about that.

I know of four ways to have a global identifier:
- Use OIDs
- Use DNS / URI
- Probabilistically using a big enough byte string
- A new registry, perhaps IANA (but we probably don't want this)

The PR allows all but the last, but this could be reduced to just one or two of the above.

PR looks great to me, except that would I agree with reducing it to one or two.
Since the ability to take a value and resolve it to something meaningful is useful in many cases (logging, wireshark analysis, etc.), I would remove the third option.

OIDs, encoded as int arrays, probably compress the best so if only one, then I'd pick that one.  URIs are convenient though also so if two, then that's my second pick.

I don't see this claim as essential for EAT, but I committed to working through this with TEEP. I'm fine with this PR going into a TEEP document rather than EAT.

The notion of HW class ID is not specific to TEEs, hence the request to put it in EAT rather than in anything that would imply use is limited to TEEs (hence not in a TEEP document).

-Dave

_______________________________________________
TEEP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teep

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.