Re: [Rats] Supply Chain Attestation (was Re: 3 Use cases)

Laurence Lundblade <> Tue, 08 October 2019 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B04E612083B for <>; Tue, 8 Oct 2019 07:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GknDuzaHrk7k for <>; Tue, 8 Oct 2019 07:27:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2441B120810 for <>; Tue, 8 Oct 2019 07:27:52 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id HqSti08m5YE8lHqStiK6kG; Tue, 08 Oct 2019 07:27:51 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Laurence Lundblade <>
In-Reply-To: <>
Date: Tue, 8 Oct 2019 07:27:50 -0700
Cc: Kathleen Moriarty <>, Michael Richardson <>, "Oliver, Ian (Nokia - FI/Espoo)" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Henk Birkholz <>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfItLKnLKP4mDdeFM3uFxDdaRuLfw/Y7xnZPrCnkqHwA//M1eNX3aI2d7RXmPfjbUfTvO/dZZjH1sQHdkFw6So26UMAcy2IH1pAu9lIdvgVy+fwzu6SNK OvSTxhIcVoCafPtKgMBHFwYDymX6JP3Pt+775a/4+BmALgPpNvIQSgfr8X6tLWfCKh9CSiqc2iuTF40IiKu+AT5+nKC5UoG40P8mCOgxXSk6yOStiHKNxduu E+MmAR77xoz6NbKY/76jq8FQnGAc4Sg1Bh16J+WTMMddIoRFM7LZMqX8uSvOd0lGcoGlkzeQBjPB+2rfUGAtmCOPwB5caMxLE20q/MtEdUs=
Archived-At: <>
Subject: Re: [Rats] Supply Chain Attestation (was Re: 3 Use cases)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Oct 2019 14:27:55 -0000

submods is an array of maps, each map containing the claims for that submod. Each of these maps also has a text string that is the submod_name.

The submods array itself has a key defined by the standard.

So you can do 
   (eat (submods (submod) (submod) (submod) )) where submod looks a lot like an eat except it is not individually signed and has the submod_name claim

You can also have all the combos:

   (eat (eat) (submods (submod) (submod)))
   (eat (eat) (submods (submod (eat) (eat) (submod)) (submod (submods (submod) (submod (eat))))

As the document stands now there is one key for a nested eat. It is different than submods. To do (eat (eat)(eat)(eat)) all the nested eats would have the same key. That is probably not the best and it should go to the array like submods.

We do need better examples for all this.

Probably the main eat doc should allow all of this, but profiles should narrow it for particular use cases.

I see submods as used when the two entities are physically connected together by wires that can’t be easily attacked. For example they are on the same PCB on subsystems in a SoC. Also the submod is likely to be dumb and incapable of making an eat.  Putting the signing key to a device in a secure way is hard so lack of a key is probably why it can make an eat.



> On Oct 8, 2019, at 12:37 AM, Henk Birkholz <> wrote:
> Hi Laurence,
> thanks for the clarification! If you nest a pre-defined submod in an EAT, I assume the key is defined in the same specification.
> If I nest an EAT in an EAT (Michael gave two good examples that can be combined), where do I define the key for that? In the nested EAT specification or in the nesting EAT specification? I'd assume in the nested EAT specification?
> A special (or actualy the currently most common) case would be the current base EAT specification. Should that come with its own "self-nesting" key then?
> Viele Grüße,
> Henk
> On 08.10.19 03:57, Laurence Lundblade wrote:
>> EAT has three mechanisms that can apply here:
>>    _Nested EATs_
>>    One signed EAT is embedded in another signed EAT. The signature of
>>    the top-level one is across full COSE structure of the nested EAT.
>>    This is important to bind the nested EAT (perhaps EATs) with the
>>    top-level one and all it claims.
>>    _submods_
>>    These are subordinate maps of claims that are not separately signed.
>>    The relation to the attester is explicitly labeled. For example an
>>    EAT may span 4 chips each of which has its own OEM and HW Version.
>>    There would probably be 3 submods plus the chip doing the attester.
>>    Each would have an OEM claim and a HW Version claim.
>>    _Custom Claims_
>>    There’s no preclusion to some complex claim with many levels of
>>    nesting of maps and arrays.  So, no it is not true that an EAT can
>>    only include a nested EAT.
>> As Ned says, the Verifier is likely to expect a lot of this and fail if not as required. The profile it adheres to might be liberal about lots of extra unknown submods, nested eats and custom claims or not liberal at all.
>> I after a good structure for all of these that is flexible and useful. Would be interested in folks trying to use these to construct EATs for use cases as examples.
>> LL
>>> On Oct 7, 2019, at 11:45 AM, Henk Birkholz < <>> wrote:
>>> That brings up an interesting topic.
>>> If you want to nest objects/maps in EAT, do you have to define a separate EAT for each layer or can you define nested (potentially multiple) sub-structures as a single EAT flavor/specification? Like a "required nesting that is predefined".
>>> I'd assume so, but I think that is not spelled out explicitly - as an EAT can only include nested EATs?
>>> Viele Grüße,
>>> Henk
>>> On 07.10.19 18:08, Kathleen Moriarty wrote:
>>>> On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson < <> <>> wrote:
>>>>    {sorry for the time-warp email, responding to you was important to me}
>>>>    Oliver, Ian (Nokia - FI/Espoo) < <>
>>>>    <>> wrote:
>>>>         > Supply Chain Attestation
>>>>         > A device is shipped from an OEM via some delivery mechanism
>>>>    and is
>>>>         > received by a customer. The customer requires assurance that
>>>>    the device
>>>>         > has not been tampered with. This differs from the usual
>>>>    attestation
>>>>         > scenarios between a device/element and attestation
>>>>    server/verifier in
>>>>         > that this requires knowledge of the partial or full
>>>>    configuration of
>>>>         > the device being shipped and configured before introduction
>>>>    into the
>>>>         > customer's environment.
>>>>         > This use case then requires interaction between two
>>>>    attestation points
>>>>         > to ensure that the integrity of the device has not changed
>>>>    with regards
>>>>         > to a) the device, b) the original [possibly partial]
>>>>    configuration, c)
>>>>         > the device manufacturer's measurements and d) the receiver -
>>>>    customer's
>>>>         > - measurements..
>>>>    There are quite a number of entities that are looking for the
>>>>    attestation
>>>>    that involves not the device, but the configuration as well.
>>>>    I think that this fits into 5.1: Device Capabilities/Firmware Attestion.
>>>>    I think that the need for sensitivity to configuration is generally
>>>>    something
>>>>    that the TCG RIV work:
>>>>          The TCG RIV Reference Document addresses the problem of
>>>>    knowing if a networking device
>>>>          should be part of a network, if it belongs to the operator,
>>>>    and if it is RUNNING
>>>>    Guy has posted their document as
>>>>    draft-fedorkow-rats-network-device-attestation, which
>>>>    makes it much more accessible if you aren't a TCG member (I'm not).
>>>>    You allude (but are perhaps not explicit enough) in your second
>>>>    paragraph
>>>>    that there is some interaction between different attesters to
>>>>    generate the
>>>>    required set of claims needed.  Do you imagine that this is done via
>>>>    multiple
>>>>    signatures on a claim set, or some kind of nested claim structure,
>>>>    or perhaps
>>>>    use of passport claim for one part, followed by a background-check style
>>>>    process for the second. (Dave Thaler's slides included that option too)
>>>> I would guess a nested claim structure so that you could 'wrap'  a claim set and signature of code that is relied upon.  Having a standard format and evaluation method (TEEP) for this use case is then very important across vendors int he supply chain.  Your other suggestion could work as well, but the consistent ablity to validate will be very important.  I'd like to follow the discussion and thoughts of others.
>>>> Best regards,
>>>> Kathleen
>>>>    --     ]               Never tell me the odds!                 | ipv6 mesh
>>>>    networks [
>>>>    ]   Michael Richardson, Sandelman Software Works        | network
>>>>    architect  [
>>>>    ] <> <>
>>>>        |   ruby on rails    [
>>>>    _______________________________________________
>>>>    RATS mailing list
>>>> <> <>
>>>> -- 
>>>> Best regards,
>>>> Kathleen
>>>> _______________________________________________
>>>> RATS mailing list
>>>> <>
>>> _______________________________________________
>>> RATS mailing list
>>> <>