Hi Rares,
The current 'certtool' implementation generates certificates based on the Chain of Trust (CoT) specified via the command line, such as TBBR, DualRoot, or CCA. Additionally, platforms can define their own OIDs using the same macros and/or extend the CoT with
platform-specific information.
In your example, the TOS FW content certificate is part of 'tbb_cert.c' and relies on the 'Trusted FW NV counter' as per the TBBR specification. Since TBBR is now retired, it should either be completely removed and replaced with the latest guidelines or retained
temporarily while introducing a new CoT to allow a transition period before TBBR's removal.
An alternative approach is to enable platforms to override the TBBR configuration and define their own CoT while ensuring compliance with the latest guidelines. This is probably be the approach meanwhile for you.
This needs to be discussed with platform owners and the community before proceeding further. As of now, there is no immediate plan to support this latest guideline.
Thanks,
Manish Badarkhe
From: Rares Constantin <rares.constantin@nxp.com>
Sent: 12 February 2025 14:41
To: Manish Badarkhe <Manish.Badarkhe@arm.com>; tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: Re: TBBR: Question about the available Non Volatile Counters
Hi Manish,
Thank you for your response!
Regarding the example given in my previous e-mail, let's say a new non-volatile counter is needed for the Trusted OS content certificate instead of the `TRUSTED_FW_NVCOUNTER` extension [1], meaning that a platform-defined certificate for Trusted OS content
that adds the custom non-volatile counter should be used instead of the standard one that can be found at the previous link. This would be resolved by the ARM DEN0072 specification if an individual non-volatile counter is used for each authenticated image.
Do you plan on supporting the new specification in the future?
Thank you!
________________________________________
From: Manish Badarkhe <Manish.Badarkhe@arm.com>
Sent: Wednesday, February 12, 2025 2:58 PM
To: tf-a@lists.trustedfirmware.org; Rares Constantin <rares.constantin@nxp.com>
Subject: Re: TBBR: Question about the available Non Volatile Counters
Hi Rares,
Thank you for your email.
You're right that the TBBR specification (DEN0006D) has been retired, and the default cert_create tool still supports it. However, this doesn't prevent platforms from implementing their own CoT in a customized manner while still using the tool. You can see
how a few platforms in TF-A have implemented platform-defined certificates, keys, and extensions in [1] and [2].
Hope this helps.
[2]:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17186
Thanks,
Manish Badarkhe
________________________________________
From: Rares Constantin via TF-A <
mailto:tf-a@lists.trustedfirmware.org>
Sent: 10 February 2025 08:42
To:
mailto:tf-a@lists.trustedfirmware.org <
mailto:tf-a@lists.trustedfirmware.org>
Subject: [TF-A] TBBR: Question about the available Non Volatile Counters
Hi,
I have a question regarding the TBBR implementation for non-volatile counters in TF-A.
While looking through the code and documentation for Trusted Boot authentication options, it was not clear why there are only two non-volatile counters for the Trusted and Non-Trusted worlds (`TRUSTED_FW_NVCOUNTER` and `NON_TRUSTED_FW_NVCOUNTER`). This is true
for the Arm DEN0006D specification, but it was retired and ARM DEN0072 is the current specification. Is there any specific reason why there isn't a counter for each authenticated image declared and created by `cert_create` or is the retired specification the
only reason? This limits the non-volatile counter extensions for all certificates, meaning that the Trusted OS content certificate for example cannot be authenticated with another extension, unless I add a custom certificate with another non-volatile counter
extension and a new command line option.
To quote the ARM DEN0072 TBBR specification [source:
https://developer.arm.com/documentation/den0072/latest]: "It is recommended to implement as many version counters as there are images, where each image can use a separate counter without affecting other images. However, the number of rollback counters that
can practically be supported is implementation dependent.".
Thank you!
--
TF-A mailing list --
mailto:tf-a@lists.trustedfirmware.org
To unsubscribe send an email to
mailto:tf-a-leave@lists.trustedfirmware.org