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

[Akira Tsukamoto <[e-mail]>]

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:
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Akira Tsukamoto
>     Sent: Monday, April 13, 2020 7:46 AM
>     To: teep <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     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://clicktime.symantec.com/38kWqaWA3sW14euWCDuBdWf7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F4
> 
>     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
>     [e-mail] <mailto:[e-mail]>
>     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.
> 
>     _______________________________________________
>     TEEP mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>