Hi David,
One of the goals of the MCUboot community is to make sure that however the SUIT manifest is implemented, it must be semantically the same as the existing TLV-format manifest. An solution is to just treat the existing version as a 32-bit number (ignoring the build-id, which I think is supposed to be the case, anyway).
I agree, that this would be the simplest solution, but might be a bit rigid. I see the additional counter solution a bit more flexible: 1.) If version number is always incremented and directly used as security counter, then no SW downgrade is possible at all. However might this is the goal in some use case and it is perfectly fine. Does SUIT consider downgrade as valid scenario? 2.) I see the benefit of additional security counter in these cases: - It does not necessarily need to increase with each released SW version, so intentional downgrade (not revert) is possible, and might useful is some scenarios for end user. - If security counter is saved to NV counter then might the representation range of the NV counter is limited, so a 32bit counter cannot be stored.
I have suggested to have additional counter, mainly due to the limited representation range of NV counters. Additional security counter requires the introduction of a new command line option in the imgtool script to specify the value of security counter. But if the value is not explicitly provided then script can take the version number (ignoring the build-id) and turns into security counter. This would give the flexibility of the user, if he does not care then the version number will be used as security counter, if he do care for whatever reason then explicitly value will be used as security counter.
If we always increase the security counter value, someone still running the immediately following image will be prevented from rolling back to the version with the security flaw, whereas if we reused the values, it might be necessary to try to force them to upgrade to a new version that has the counter increased.
Could you elaborate this a bit? I did not get it...
Also, I think it is important to clarify that the security counter is not required for anti-rollback, it only protects the anti-rollback implementation from a specific threat: something that is able to replace the primary firmware image outside of the control of the bootloader. The cost is that implementing a security counter generally requires specific hardware just for that purpose. An entirely software anti-rollback protects against other threats, including the common case of using the ordinary firmware upgrade process.
You are right. The user needs to decide whether what level of threat he wants to mitigate. The implementation can cover both possibility: SW only(no NV counter) and HW supported (saved to NV counter) and it can be configured by build time.
Tamas
-----Original Message----- From: David Brown david.brown@linaro.org Sent: 11 March 2019 18:41 To: Tamas Ban Tamas.Ban@arm.com Cc: tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: Re: [TF-M] Trusted boot - rollback protection
On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote:
Please see the following link for a design proposal on anti-rollback protection in trusted boot:
https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollba ck_protection/
Somewhat related, as I've been working through a prototype implementation of SUIT, the SUIT manifest also wants what they call a "sequence number", which is a monotonically increasing number associated with each version. They've kind of decided they don't want to have to do anything like semantic version parsing as part of the firmware upgrade.
I think this sequence number serves the same purpose as this security counter (except that the sequence number is required to increase with each software relase).
One of the goals of the MCUboot community is to make sure that however the SUIT manifest is implemented, it must be semantically the same as the existing TLV-format manifest. An easy solution is to just treat the existing version as a 32-bit number (ignoring the build-id, which I think is supposed to be the case, anyway).
As far as the possibility of re-using the same security counter value, I don't think that is something that should be done. In general, it isn't possible to know where security bugs will be found in an image. If we always increase the security counter value, someone still running the immediately following image will be prevented from rolling back to the version with the security flaw, whereas if we reused the values, it might be necessary to try to force them to upgrade to a new version that has the counter increased.
Also, I think it is important to clarify that the security counter is not required for anti-rollback, it only protects the anti-rollback implementation from a specific threat: something that is able to replace the primary firmware image outside of the control of the bootloader. The cost is that implementing a security counter generally requires specific hardware just for that purpose. An entirely software anti-rollback protects against other threats, including the common case of using the ordinary firmware upgrade process.
David