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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 May 2020 09:13:01 +0000

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 <[email-masked]> On Behalf Of Akira Tsukamoto
Sent: Monday, April 13, 2020 7:46 AM
To: teep <[email-masked]>; [email-masked]
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
[email-masked]
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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 May 2020 06:49:15 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > 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?

That seems correct to me.
It seems to wander into some SUIT/TEEP/CoSWID considerations.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mingliang Pei <[email-masked]>
Date: Tue, 12 May 2020 23:00:30 -0700

One of the questions is: who creates or assigns an ID as the TA_ID to a TA?

A TAM is responsible to install, upgrade, or delete a TA. It may give it an
identifier to track it. Different versions of TAs may use the same TA ID
but add a version convention. This allows a TAM to identify a TA for
upgrade.

To ensure uniqueness, a UUID is a good choice for a TA ID where a TAM may
create to be unique.

Should the TA developer create and provide TA ID to the downstream systems?
It can but I think a TAM may override it if it needs to do so. The TA
developer should define a friendly display name for the TA. When a TAM
manages many TAs, a TAM operator will like to see friendly display names
rather than the opaque TA IDs that are created for machine consumption. A
TAM may locally maintain a mapping between TA names and TA IDs.

With SUIT compatibility, a UUID Component ID for TA ID can work. Is there a
place holder in SUIT for a TA friendly name? A TA name doesn't need to be
passed to the TEEs for management; it may help debugging logging but may
not be worthy of the bandwidth and size cost.

Thanks,

Ming

On Tue, May 12, 2020 at 2:14 AM Hannes Tschofenig <[email-masked]>
wrote:

> 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
>
> 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.
>
> https://clicktime.symantec.com/38kWqaWA3sW14euWCDuBdWf7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F4
>
> The usage of TA_ID in TEEP message is to distinguish the required TA in
> the device by parsing of identification id.
>     -  Image Digest. # This is version of TA It is up to the user who
> would like to add optional parameters for the seed.
>
> 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
>
> https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
> 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.
>
> https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: Akira Tsukamoto <[email-masked]>
Date: Wed, 13 May 2020 20:17:39 +0900

Hi

What I was thinking of images similar to the pseudocode bellow.

typedef struct {
     uint16_t vender_id; /* RFC4112, type5, 128 bit, 16 byte */
     uint16_t class_id;  /* RFC4112, type5, 128 bit, 16 byte */
     uint16_t device_id; /* device unique-ID, 128 bit, 16 byte */
} teep_uid_t;

     digest[MDSIZE];
     teep_uid_t uid;
     sha256_ctx_t ctx;
     uint32_t hash_uid; /* 256 bit */

     memset(digest, 0, sizeof(digest));
     memset(&uid, 0, sizeof(uid));

     sha256_init(&ctx, MDSIZE);

     sha256_update(&ctx, &uid.vender_id, sizeof(uid.vender_id));
     sha256_update(&ctx, &uid.class_id, sizeof(uid.class_id));
     sha256_update(&ctx, &uid.device_id, sizeof(uid.device_id));
     sha256_final(digest, &ctx);

     convert_d_uid(digest, hash_uid);

Then use the hash_uid as TA_ID in the teep message.

This way the TAM do not have to separately store the TAs with
vender_id and/or class_id.

And good definition of vender_id, class_id and device_id are in the suit manifest draft,
therefor, we do not have to mention the details in teep drafts.

We have to specify which sha256 or anything else to use.

-Akira

On 5/13/20 15:00, Mingliang Pei wrote:
> A TAM is responsible to install, upgrade, or delete a TA. It may give it an identifier to track it. Different versions of TAs may use the same TA ID but add a version convention. This allows a TAM to identify a TA for upgrade.
> 
> To ensure uniqueness, a UUID is a good choice for a TA ID where a TAM may create to be unique.
> 
> Should the TA developer create and provide TA ID to the downstream systems? It can but I think a TAM may override it if it needs to do so. The TA developer should define a friendly display name for the TA. When a TAM manages many TAs, a TAM operator will like to see friendly display names rather than the opaque TA IDs that are created for machine consumption. A TAM may locally maintain a mapping between TA names and TA IDs.
> 
> With SUIT compatibility, a UUID Component ID for TA ID can work. Is there a place holder in SUIT for a TA friendly name? A TA name doesn't need to be passed to the TEEs for management; it may help debugging logging but may not be worthy of the bandwidth and size cost.
> 
> Thanks,
> 
> Ming
> 
> 
> On Tue, May 12, 2020 at 2:14 AM Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Akira,
> 
>     From: TEEP <[email-masked] <mailto:[email-masked]>> On Behalf Of Akira Tsukamoto
>     To: teep <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 17 May 2020 23:19:37 -0700

> We have to specify which sha256 or anything else to use.

Note that BCP 201 says you have to be able to support multiple algorithms.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 May 2020 10:20:20 +0000

Hi Ben,

BCP 201 does not apply here because we are not using the algorithm for use with cryptography but rather to shorten the identifier while still reducing name collisions.

Ciao
Hannes

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Sent: Monday, May 18, 2020 8:20 AM
To: Akira Tsukamoto <[email-masked]>
Cc: Mingliang Pei <[email-masked]>; Hannes Tschofenig <[email-masked]>; teep <[email-masked]>; [email-masked]
Subject: Re: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse

-Ben