Re: [Rats] [sacm] CoSWID and EAT and CWT

[Henk Birkholz <[e-mail]>]

Hi Laurence,

I absolutely agree.

1.) the complexity of a solution should be appropriate to the problem.

=> EAT is very flexible and can scale from simple to (maybe even overly 
- we should avoid that) complex.

2.) It is critical to not use an overly complex solution for a simple 
problem.

3.) There could be "hardcoded" (but in that case mandating their own 
signature) CoSWID Claims for specific type/model composites that cannot 
be differentiated via their software components (because they are all 
the same, for example) and that is fine (as an analogy, I think there 
could be binary YANG telemetry that is composed of hardcoded 
building-blocks, if the device the custom subscription is created with 
is simple enough).

4.) If the boot SW is not intended to be touched, it is not touched. 
Although I think, an EAT should highlight that in it's CoSWID or a 
related claim in the EAT, to steer its "superior's"/management system's 
decision as a "hint".

5.) It should not be excluded to allow for complex composition of CoSWID 
and SUIT claims for more complex devices that can deal with elaborate 
update and remediation scenarios.

=> Again, EAT provides the flexibility for that - we should leverage 
that, I think.

Happy Thanks Giving!

Henk

p.s. alas a CoSWID will never be a "a hard-coded byte array", please 
never cut out a portion out of a CoSWID, but deliver it "in its 
entirety". Your example used the index 21 (which I assume is an example 
for an EAT Claim), but please prefix the COSE CBOR tag (if the CoSWID 
tag is signed) and always prefix the CoSWID CBOR tag (inside the body of 
the COSE envelope, too, if applicable) :)

On 28.11.19 22:53, Laurence Lundblade wrote:
> I am very much agreement with Adrian.
> 
> SUIT is far from wide adoption, yet billions of devices have 
> verified/secure boot* and do a good job of SW update. Some of these 
> devices like mobile phones have very complex boot and multifaceted SW 
> updated, other are very simple lost cost single-use devices.
> 
> For many use cases, a simple EAT with only a few claims will suffice. 
> Maybe the only claims are the UEID and the version of THE software for 
> the device because it only has one SW component. Only the mandatory 
> CoSWID fields, plus version, are filled in for the single SW component. 
> Such an EAT would have 8 claims as in the example below. It is critical 
> IMO that EAT keeps tokens for these simple use case simple. The minimum 
> CoSWID is 5 claims right now. Wouldn’t want to increase that.
> 
> Constructing the payload for this EAT is pretty simple. The only claim 
> that varies from one token to the next is the nonce. The CoSWID part 
> could be a hard-coded byte array containing the encoded CBOR since it 
> will never change. The harder part of EAT here will be COSE and signing 
> key set up, not claim construction.
> 
> Importantly, the boot SW of this simple device need not be touched. The 
> EAT implementation automatically gets the security from whatever boot 
> security it has.
> 
> Even on a complex device such as one with a TEE and TA’s, the TA’s most 
> likely get all the security from the boot sequence and TEE OS without 
> having to modify the boot sequence or the TEE OS (I am quite sure of 
> this having done it for Qualcomm's Hardware Token here 
> <https://www.qualcomm.com/products/features/mobile-security>).
> 
> LL
> 
> 
> * Generally agree with Monty’s recent definition of verified boot; some 
> people call this secure boot
> 
> 
> 18( [ / protected parameters, bstr wrapped / << { / alg / 1: -7 / ECDSA 
> 256 / } >>,
> 
> / unprotected parameters / { / kid / 4: 
> h'4173796d6d657472696345434453413 23536' / 'AsymmetricECDSA256' / },
> 
> 
> / COSE payload, the EAT, bstr wrapped / << { / nonce /
> 
> 7:h'948f8860d13a463e8e',
> 
> / UEID /
> 
> 8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f',
> 
> / The CoSWID /
> 
> 21: {
> 
> / tag-id, globally unique identifier for the software component /
> 
>            0: "trustedfirmware.org/TF-M <http://trustedfirmware.org/TF-M>",
> 
> 
>            / tag-version (here: 0, i.e. initial tag) /
> 
>            12: 0,
> 
> 
>            / software component name /
> 
>            1: "TF-M",
> 
> 
>            / version of the software component /
> 
>            13: "1.0.0-rc1+build.123",
> 
> 
> 
>            / entity, i.e. organizations responsible for producing or
>         releasing
> 
>              the software component /
> 
>            2: {
> 
>              / entity name /
> 
>              31: "Linaro Limited”,
> 
> 
>             / entity role (here: software creator) /
> 
>             33: 2,
> 
> 
>        },
> 
> 
>        }
> 
>     } >>,
> 
> 
>     / signature / h'5427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f
>     9179bc3d7438bacaca5acd08c8d4d4f96131680c42
>     9a01f85951ecee743a52b9b63632c57209120e1c9e 30'
> 
>     ]
> 
> )
> 
> 
> 
> 
> 
>> On Nov 27, 2019, at 9:13 AM, Adrian Shaw <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> While there is some synergy with the SUIT definition, I’m unconvinced 
>> that it should be the way to express a software component metadata. 
>> Firstly, there are legacy systems without SUIT that would want to use 
>> EAT, and such a dependency would make it hard for incremental 
>> adoption. Secondly, not all the data from the SUIT manifest is needed 
>> for this claim.
>>
>> Adrian
>>
>>> On 27 Nov 2019, at 16:59, Thomas Fossati <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>> Hi Henk
>>>
>>> Thanks very much for your input.
>>>
>>> On 27/11/2019, 13:24, "Henk Birkholz" 
>>> <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>> yes there are ways to deal with firmware in SWID, namely the resource
>>>> type (index 19) in the set of SWID resource-collection [1] in
>>>> combination with the rel type (index 40) entries.
>>>>
>>>> This way, you would not have to use filesystem-items, but this way is
>>>> also a bit clunky and would require an informational guidance document
>>>> describing how to use *SWID for that.
>>>
>>> That's interesting because initially I also tried to use the resource
>>> type -- which looked like the less wrong among all the available types
>>> in the resource collection.  However it wasn't clear to me how to
>>> associate a checksum to the component, hence I went for the
>>> filesystem-item.  Maybe I was just looking in the wrong place or maybe,
>>> as you say, there's a magic firmware recipe that's worth documenting
>>> here.
>>>
>>>> There are some quite smart ways to do that actually with
>>>> filesystem-items, but I think it is more feasible to use a SUIT
>>>> manifest here to describe everything relevant to the "firmware thingy"
>>>> and then put a CoSWID into the SUIT manifest's outer wrapper [2] that
>>>> then represents the rest of the semantics that is not covered by the
>>>> manifest but by CoSWID. This method is fine, as the COSE envelope
>>>> around the EAT will make tempering with the outer wrapper of the SUIT
>>>> Manifest evident.
>>>>
>>>> I think that is a more elegant way to do it, actually, and the reason
>>>> why issue #46 in the EAT repo proposes to define a Claim to include a
>>>> SUIT Manifest in an EAT, too.
>>>
>>> I'll look into this, thanks for the pointer.
>>>
>>> Stepping back for a second and looking from the perspective of my
>>> immediate requirement (i.e., "Is it possible to translate PSA's software
>>> component claim using purely EAT constructs?"), ideally I'd like to have
>>> something that is expressive enough to encode my semantics (i.e.: SW
>>> component name, version, signer and measurement) without being overly
>>> complex.
>>>
>>> So my knee-jerk reaction is if that implies pulling a dependency on
>>> SUIT maybe it's a bit too much?  But I confess haven't yet looked at
>>> the details of your proposal nor I can claim enough SUIT-foo to really
>>> grok the complexity involved.  As said, I'll have a look shortly.
>>>
>>> cheers!
>>>
>>> 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.
>>> _______________________________________________
>>> RATS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>> 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.
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
>