Doesn't PSA require 32-bits out of the counter?
PSA TBSA M- v1.0(https://pages.arm.com/psa-resources-tbsa-m.html) requires to have at least: - Trusted firmware version counter range is: 0-63 - Non-trusted firmware version counter range is: 0-255
Due to this limited range I think it is desirable to have an implementation which is compliant with the architecture. So I still supports the idea to distinguish the security counter and the firmware version number. However I see your points that might a device does not implements HW counters, but still requires to have in place certain level of rollback protection. I have opened a ticket to implement rollback protection to those device where HW counter is not in place: https://developer.trustedfirmware.org/T351
Tamas
-----Original Message----- From: David Brown david.brown@linaro.org Sent: 06 May 2019 17:22 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
Sorry for the late reply.
On Thu, Apr 11, 2019 at 03:00:24PM +0000, Tamas Ban wrote:
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?
I would argue that your point is both correct, and arguably desirable. It all depends on how meaningful your development process makes revision numbers. I would see rolling back like this as reverting all of the newer changes, and would argue that it should just get a newer version number.
There is a lot of potential for confusion by having the version numbers and the "counter" be uncorrelated spaces.
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.
Until you discover a bug in an earlier version but not a later version of one of these equivalent versions.
- 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.
Doesn't PSA require 32-bits out of the counter?
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.
Agreed, it is probably best to give the user (being the user producing the images) the flexibility here.
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...
It isn't always obvious right away that a given fix to the code is indeed a security fix. It is possible, for example for there to be a bug in version 1.2.3 that is fixed in 1.2.4, but at the time of the fix it didn't seem like this was a security problem. Only later do we discover that the bug in 1.2.3 was exploitable. If they had the same counter value, though, there is no way to go back and prevent downgrades from 1.2.4 to 1.2.3.
From a security perspective, I would argue that the rule should just be that no earlier than current version can be installed, and rollbacks need to be explicit, by giving newer version numbers.
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.
I'm mostly trying to counter what seems to be the common notion that without a hardware counter there is no anti-rollback protection, which is not the case. The hardware protects against some specific attacks, not against rollback in general.
David