Re: [Teep] [Suit] SUIT MTI: key agreement algorithm to pair with HSSLMS

[Akira Tsukamoto <[e-mail]>]

Resending, forgot to add teep-wg to the recipient.

Hi Brendan, Hannes and other TEEPers,

I am considering removing the algorithms written in the TEEP Protocol.

The TEEP Protocol depends on the SUIT MTI draft for the algorithms in suit format
and in the TEEP Protocol draft it specifies the 
  suit-sha256-es256/eddsa-ecdh-a128gcm
which were the same on the SUIT MTI until the recent -02 updates.

After the SUIT MTI-02 have moved to the 
  suit-sha256-es256/eddsa-ecdh-a128ctr
I prefer removing specifying the algorithms in the
future TEEP Protocol draft and completely rely on
the SUIT MTI for which algorithms to be used in the TEEP also.

Appreciate for any comments,

Best,
Akira

On 8/1/2023 4:03 PM, Tschofenig, Hannes wrote:
> Hi Michael, 
> 
> with item (3) there is just no encryption offered by the given ciphersuite. 
> With item (2) there is no requirement that every bootloader is provisioned with the same symmetric key.
> AES-KW allows you to use device-unique symmetric secrets. 
> 
> Ciao
> Hannes
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Suit <[e-mail]> Im Auftrag von Michael Richardson
> Gesendet: Montag, 31. Juli 2023 16:00
> An: Brendan Moran <[e-mail]>; suit <[e-mail]>
> Betreff: Re: [Suit] SUIT MTI: key agreement algorithm to pair with HSSLMS
> 
> 
> Brendan Moran <[e-mail]> wrote:
>     > There is currently no standardised PQC key agreement (or encapsulation)
>     > algorithm. This means that a SUIT MTI profile with HSSLMS is left with
>     > three choices, none of which seems particularly good.
> 
>     > 1. Use a classical asymmetric key agreement algorithm 2. Use a
>     > symmetric key agreement algorithm 3. Use no key agreement algorithm
> 
> I think that I have to vote for (1).
> 
> If I understand (2), then every single instance of the product bootloader will have to have the same symmetric key loaded?  I guess there is some process used to derive the actual key.
> 
> I'm not sure I understand (3).  Does that mean every firmware is encrypted with exactly the same symmetric key?  Or that there is no encryption at all?
> 
>     > My initial suggestion was to use classical asymmetric key agreement. I
>     > wonder if A128KW might be more appropriate.
> 
> I think that to answer this question properly one needds to know what threats are being mitigated by firmware encryption.  I think it's mostly covering up poor code, poorly done cloud authentication and other embarassing things that a good SBOM will eventually reveal.
> 
> Is it okay if a ten year old firmware image is decryptable?
> (It can't be modified due to signatures, and the anti-rollback means no device will ever load it)
> 
> Are firmware images stored encrypted on the device, or decrypted when they are loaded?  This matters, because in the latter case, we could have updates to the encryption algorithm through the normal firmware update process.
> (Assuming new firmware is downloaded by the full stack)
> 
> If firmware is decrypted by the boot loader, or by the CPU directly, then we might not be able to update things easily.  Of course, in that case, a per-device encrypted key to which the downloaded firmware is re-encrypted might be a better choice in general.
>