Re: [CFRG] [EXTERNAL] pq firmware signing question

Stephen Farrell wrote:
>Thanks. Can you provide (ptrs to) more details? Other that for a very tiny range of devices, I don't get why the upgraded device can't change the range of sig algs usable. I'm also surprised that (I guess) the root of trust for the signing key also can't be changed ever.

>What I'm trying to understand is how prevalent such devices might be, and therefore how much to weigh their specific requirements against what's needed for almost all devices that don't have those specific requirements.

Working for hardware manufacturer, I can confirm that burning trust anchors into hardware is extremely common. You can burn several keys but you cannot change them.

This use is very prevalent. Some requirement, that may or may not affect CFRG:

  *   We need ML-DSA and SLH-DSA asap. For many companies this is priority number one, not ML-KEM. ML-KEM can be added in software, and for many systems a malicious firmware update in 20 years is much worse that that a quantum computer decrypting information in 20 years. The application data is often is encrypted on a higher layer, and early CRQCs (if they ever are built) is expected to be expensive and to target high-value resources. Uploading a fake firware is typically worth much more for an attacker than decrypting a small amount of metadata (assuming best practice of rekying with ephemeral-ephemeral ECDH every 1 hour and 1-100 GB is followed). X25519 is extremely fast.

  *   The conservative SLH-DSA is security wise quite attractive for this use case but the keys are a bit big. My hardware people tells me that they want to keep the amount of burned bytes small. As ML-DSA is in CNSA 2.0 my feeling is that ML-DSA is more commercially available. ML-DSA also have better performance and smaller keys.

  *   The private key in trust anchors is typically used a small amount of times. SLH-DSA tuned for much less than 2^64 signatures is a good fit. The signing speed is almost irrelevant. The verification speed is important.

  *   Verifying two signatures, e.g., ML-DSA + EdDSA makes sense for this use case, but we strongly need ML-DSA standalone if that is required for CNSA 2.0 compliance.

  *   As ML-DSA and ML-KEM relies on SHA-3/Keccak I think it make sense that all protocols allow KMAC as an option for key derivation. Forcing people to implement both HMAC-SHA-2 and KMAC does not make sense long-term.

Cheers,
John

From: CFRG <cfrg-bounces@irtf.org> on behalf of Falko Strenzke <falko.strenzke@mtg.de>
Date: Tuesday, 19 March 2024 at 00:36
To: Kris Kwiatkowski <kris@amongbytes.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, cfrg@irtf.org <Cfrg@irtf.org>
Subject: Re: [CFRG] [EXTERNAL] pq firmware signing question
Some people who received this message don't often get email from falko.strenzke@mtg.de. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

And this is a (one of the many on the net) summary of NXP's secure boot mechanism, which also burns the trust anchor certificates into the device's memory permanently:

https://variwiki.com/index.php?title=High_Assurance_Boot_MX8&release=RELEASE_DUNFELL_V1.5_VAR-SOM-MX8

NXP i.MX platforms are application processors, meaning they are meant to run operating systems like Linux as the basis for a wide range of industrial and consumer electronics applications.

For the background: permanent trust anchors for firmware update verification are needed to achieve a sufficient level of trust in the device's ability to always perform secure updates, no matter what type of attacker – remote or local – may have previously interfered with the device.

- Falko
Am 17.03.24 um 23:12 schrieb Kris Kwiatkowski:

On 18 Mar 2024, at 08:00, Stephen Farrell <stephen.farrell@cs.tcd.ie><mailto:stephen.farrell@cs.tcd.ie> wrote:

What I'm trying to understand is how prevalent such devices might be,

and therefore how much to weigh their specific requirements against

what's needed for almost all devices that don't have those specific

requirements.

Quite prevalent - whatever needs secure boot (mobile phones and SmartNICs are two types of devices I personally worked with). Section about secure boot in ARM documentation is good place to start:

https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot

_______________________________________________

CFRG mailing list

CFRG@irtf.org<mailto:CFRG@irtf.org>

https://mailman.irtf.org/mailman/listinfo/cfrg
--

MTG AG
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000 24
E-Mail: falko.strenzke@mtg.de<mailto:falko.strenzke@mtg.de>
Web: mtg.de<https://www.mtg.de/>

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy<https://www.mtg.de/en/privacy-policy>