Add support for optional anti-rollback protection

[aditihilbert]

Some systems require anti-rollback protection to be in place. The easiest way for us to do this is to prevent upgrades to versions that are older than the currently running version.

In order to do this, we need to define what the ordering means with the version fields, and then add an option to enforce it.

[tamasban]

I would like to open a discussion about the implementation of rollback protection in MCUBoot:

• Should it be mandatory or just optional?
• How to implement it?
• Where to store the rollback counter (header or TLV section)?
• How does SUIT manifest handle it?
• Security concerns with image swapping

Aim of anti-rollback protection:

• Prevent to downgrade the device to an older version of SW, which contains a known security vulnerability.
• Manifest data of firmware images must contain a security counter, which is increased if a potential security vulnerability is fixed in the new version.
• Boot loader must ensure that only such a firmware is accepted for update which related security counter is the same or higher than the security counter of the current active image on the device.

Some potential implementation of rollback protection:

• Always use the latest version. Compare the full version numbers which are extracted from image header and do not accept any downgrade.
• Check only a part of the image version. i.e: if (major+minor) part of version number must be the same or higher to accept an image for update. Beyond these the rest of the image version does not matter. Downgrading image up to certain image version is possible.
• Introduce a new security counter which can be independent from image main version number. This counter must be increased only in the case if a potential security vulnerability is fixed in the new version of the SW. After this version will be deployed then it is not allowed to downgrade to older ones.

What to use for security counter:

• Security counter must be in stored in NVM memory (on-chip eFlash, OTP, trusted subsytem).
• Version number in image header can be a good candidate because it is in the integrity protected part of the image and active image is stored in eFlash.
• Introduce a new rollback/security counter. This counter should be placed in the integrity protected part of the image. This could go in the header but there is not too much empty field in the header.

Extend the the integrity protection to some part of the TLV section:

• Currently the TLV section is not integrity protected, not covered by the hash & signature.
• It would be beneficial to cover some part of the TLV section with the signature. In this case new TLV-s could be introduced easily which are requires integrity protection and the header should not but overloaded. There is an implementation of this in multi image boot PR. In that case the dependency TLV entries are stored in the protected part of the TLV section.

Set the value of security counter:

• Add a new command line switch to the image tool script which would get an explicit value from command line and set that as security counter.
• Make possible to derive somehow from image version number. Possible polices to derive:
  • Use major+minor+version to produce security counter. Could be a default option. If no explicit security counter was provided.
  • Use only major+minor to produce security counter.
  • etc.

Integration with update modes:

• Overwrite only:
  • The security counter of active and new image must be compared and only updates with the same or higher security counter value are accepted.
• Swap operation:
  • In case of swap operation it might happens that the old image will be reverted back after a unsuccessful SW update.
  • If a malicious actor can overwrite the status fields (image-ok) in the image trailer (slot-0) and can download a previous vulnerable image to slot-1 then MCUBoot can be misleaded to do a revert operation and downgrade to an old, vulnerable SW. The feasibility of this threat is in question, because the attacker should be able to modify the content of the on-chip flash from remote with SW only attack.
  • A mitigation could be to have a copy of security counter:
    • In an OTP memory (eFuses) which cannot be decremented
    • In a authenticity protected on-chip flash area

Impact on code size:

• Considered to low impact
• It could be an optional feature configured at compile time.

[nvlsianpu]

• Introduce a new security counter which can be independent from image main version number. This counter must be increased only in the case if a potential security vulnerability is fixed in the new version of the SW. After this version will be deployed then it is not allowed to downgrade to older ones.

We potentially don't know vulnerability status of an application until it is exercised - reject this option.

What to use for security counter?

I would Introduce a new rollback/security counter ore use version number form image header . In most of cases it will change with firmware version, except when an older version is loaded. My consideration bases on my experience form one of my previous project.

Set the value of security counter:

I would add command-line support via imagetool.py

[davidvincze]

• Introduce a new security counter which can be independent from image main version number. This counter must be increased only in the case if a potential security vulnerability is fixed in the new version of the SW. After this version will be deployed then it is not allowed to downgrade to older ones.

We potentially don't know vulnerability status of an application until it is exercised - reject this option.

I think with this option one could have the opportunity to do intentional software downgrade to some extent and still would be able to create something like a "security boundary" to limit software downgrading.

As an option, this security counter could be updated with each firmware update (i.e. to be equal with the main image version number).

[tamasban]

I would Introduce a new rollback/security counter ore use version number form image header . In most of cases it will change with firmware version, except when an older version is loaded. My consideration bases on my experience form one of my previous project.

I might miss something but it seems very aligned to my suggestion. More strategy can be defined how to derive the security/rollback counter from image version. It can be a one to one assignment or just increase security counter if major version has changed, etc. But it can be independent at all. If operator roll out a new firmware which main goal to fix a security vulnerability then the security/rollback counter i the image must be increased. If the goal of the firmware upgrade just to fix a small operational bug then security/rollback counter can remain the same as previous image.

Security counter might saved to an OTP(eFuse) memory, which can have limited range. So too frequent update of security counter might not the best strategy.

[tamasban]

I would add command-line support via imagetool.py

Agree.

[d3zd3z]

I think we have two features that are being discussed here. @tamasban is suggesting a rollback counter, which is a hardware feature to prevent rollbacks beyond certain defined points. This hardware is now always available.

What I'm suggesting in this issue is to have a simple software anti-rollback counter that merely compares the version number of the slot1 image, and ignores that image if its version number is less than the image in slot0. This would solve many of the threat cases, although it does require issuing a new image with a new version number if it is necessary to go back to an earlier version of the firmware.

I would like to keep this issue to track the software anti-rollback, and create another issue to track implementing the HW rollback counter (which is implemented in the TF-M fork).

[d3zd3z]

HW anti-rollback counter issue will be tracked in #597.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.