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

Mingliang Pei <mingliang.pei@broadcom.com> Wed, 13 May 2020 06:00 UTC

Return-Path: <mingliang.pei@broadcom.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A703A0DCA for <suit@ietfa.amsl.com>; Tue, 12 May 2020 23:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.772
X-Spam-Level:
X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxEaznLWNsRE for <suit@ietfa.amsl.com>; Tue, 12 May 2020 23:00:44 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89963A0DC8 for <suit@ietf.org>; Tue, 12 May 2020 23:00:43 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id b26so12561226lfa.5 for <suit@ietf.org>; Tue, 12 May 2020 23:00:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=khQlIe1bsbc/hJhja0mt+CWZ6wOLrvNi/f6bUJHrnjY=; b=ZP2ZbwX5qrVPi+ucr4SpEPh5ygMhgtMUWARsH/7y3/IYbORNmKDvC6EaRo/hOJf9+Z Dr74I2potd5UHm4EjsFAmPScXR5z2uFCtDDASdlpKd03YsgGxQEd2rZ1ntXxR/eOe9A3 F9xGHH17JQa2JDhXeBqbuWyC+HkfoLFl/SaBU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=khQlIe1bsbc/hJhja0mt+CWZ6wOLrvNi/f6bUJHrnjY=; b=Z+yqsGq9LiVTtu7fQJxyFHMcXp5eKQ+cTfqJURpJZ1m6PzaS/KPpQsWXuaNkVp0PPd jPbudppqKqCCnO96ZVE+AccWJ0xuzJM0IAWpkI/Z/CverzRYtVyRIjg741KZ1W/wwTf1 vHmntlkAgIJJelcWxqs5jOXlZa+kJ3mM0lew6dGxEw17WvkkAGnGj2iwz0HektqqZRKQ kbn7kHsojv11MVgAeWijwbL4n30ULXYrAXNVpsS0QBqeZ8jpyy1RK5zBeeWNJI2CLYzC BcuFAuh9Mqwd0Aj84u9W+WOycgF74Du0wKy9j+rxY4hHIZqQiW9Glhzn8ogm9Fnx2GbE vciA==
X-Gm-Message-State: AOAM5333ANqm4PHzXJSwcHqYMxchcGFO9rE8CGonqBsqzSn/+lq/c2CX DoBEUATAzsLzgsYHy8d4xwxWGuI20sMmKF3XMt6QJg==
X-Google-Smtp-Source: ABdhPJzAHaKGfPG4z5HEDUCmHqJU2datHoRp6rNGNB0vPdF+Xe45Lr/JHngE/9Tbrb97Wt1DSW5G4VV99+5A4AX20BA=
X-Received: by 2002:a19:7004:: with SMTP id h4mr15815781lfc.148.1589349641682; Tue, 12 May 2020 23:00:41 -0700 (PDT)
MIME-Version: 1.0
References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> <AM0PR08MB37161FA69D215123ACBC632FFABE0@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB37161FA69D215123ACBC632FFABE0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Mingliang Pei <mingliang.pei@broadcom.com>
Date: Tue, 12 May 2020 23:00:30 -0700
Message-ID: <CABDGos5LfjqdK8LHijnqTiceu7E823SmA=4Vtyq144jH2Kx-Hw@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Akira Tsukamoto <akira.tsukamoto@aist.go.jp>, teep <teep@ietf.org>, "suit@ietf.org" <suit@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d7d51305a5814cc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/IAdlXU5xgHnzcBRG5kRCehFvkaU>
Subject: Re: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 06:00:46 -0000

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 <Hannes.Tschofenig@arm.com>
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 <teep-bounces@ietf.org> On Behalf Of Akira Tsukamoto
> Sent: Monday, April 13, 2020 7:46 AM
> To: teep <teep@ietf.org>rg>; 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://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
> TEEP@ietf.org
>
> 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
> TEEP@ietf.org
>
> https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>