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

[Laurence Lundblade <[e-mail]>]

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]> 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]> wrote:
>> 
>> Hi Henk
>> 
>> Thanks very much for your input.
>> 
>> On 27/11/2019, 13:24, "Henk Birkholz" <[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]
>> 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]
> https://www.ietf.org/mailman/listinfo/rats