Re: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse

Hi Akira,

I had a chat with Brendan about this topic.

In the SUIT model there is a manifest somewhere and it provides a pointer to where the binary, and other data is.
That pointer is a URI. This is used to fetch the information from some repository.

The vendor id and class id are identifiers used by the device to determine whether it is looking at a manifest that can be applied to itself. A device must not install software/firmware it is not supposed to because otherwise you can quickly DoS the device.

For me, the question is what information should the device report when it is asked what software it runs. Brendan suggested to use the Component ID and we would make recommendations regarding the construction and the uniqueness we would like to have. For example, we could say that the component id for a TA should be a UUID and the same TA binary would have the same UUID. Note that this component ID could subsequently also be used as a filename but we could also keep it separate.

What do you think?

Ciao
Hannes

-----Original Message-----
From: TEEP <teep-bounces@ietf.org> On Behalf Of Akira Tsukamoto
Sent: Monday, April 13, 2020 7:46 AM
To: teep <teep@ietf.org>; suit@ietf.org
Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse

Hi all,

I would like to restart the discussion of Unique Identifier of TA_ID in TEEP's QueryResponse which was one of the item came up at TEEP interim meeting last week.

The discussion started between the Hackathon in Singapore and Berlin.

This is the link to the github.
https://github.com/ietf-teep/teep-protocol/issues/4

After going though again, I started to have my preference.

The usage of TA_ID in TEEP message is to distinguish the required TA in the device by parsing of identification id.
The it will be good to be able to match the TA with one bstr for one TA.

I started to think hash value might work.
Using the hash value from the properties of Parameters in Section 5.4.1 in SUIT CBOR Manifest for each TA.

The generating hash from adding all the properties.
These are the requited parameters.
    -  Vendor ID.
    -  Class ID. # Could be file name for SGX, uuid for op-tee. uuid is used
                   as file name in op-tee anyway
    -  Image Digest. # This is version of TA It is up to the user who would like to add optional parameters for the seed.

We have to consider which hash function to use too, and easiest to come up is probably sha256.
The hash value of sha256 is 32 bytes which is still going to be second largest member than NONCE in TEEP message.
I prefer smaller bytes to reduce the teep message size but raw parameters of all three above would be larger than 32bytes, so it may be acceptable.

The purpose of the hash value here is mainly for prevent colliding between different TAs or different version in the TAM server.

-Akira

_______________________________________________
TEEP mailing list
TEEP@ietf.org
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.