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/rollback_pr...
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
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
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
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
tf-m@lists.trustedfirmware.org
-
David Brown -
Tamas Ban