Implementing the 10 Security Goals – Anti-rollback Explained

Determined hackers are always searching for ways to undermine the security of an Internet of Things (IoT) device, and its firmware can be an easy target because it may have known vulnerabilities. It is one of the reasons product developers regularly review and update their firmware. However, the challenge is ensuring the benefits of a security fix are delivered before an attacker can compromise the device or its data.

In this blog, I’ll explain how you can help to protect a device from a cyberattack by preventing unauthorized rollback. I’ll set out our reasons for including anti-rollback as one of the PSA Certified 10 security goals, which highlight security best practice, and I’ll also look in detail at implementation.

PSA Certified outlines high-level IoT security principles in the 10 security goals. However, it is important to note that anti-rollback is not a good substitute for good engineering hygiene such as testing and validation before update rollout.

What is Anti-rollback?

As an industry, if we are to maximize the potential of the IoT, product developers have to be able to update firmware after a device has been deployed to provide important security fixes or to enhance the service offered to customers. However, any weaknesses in the security of this process can provide hackers with an opportunity to unravel everyone’s hard work and undermine confidence in connected devices.

You can use secure boot and secure loading processes to ensure that only authorized firmware is executed on your device. However, attackers will not stop their search for vulnerabilities there. They will often look for the weakest link in a chain and any low-hanging fruit. It is significantly easier for an attacker to exploit old firmware with a well-known vulnerability than to look for a flaw in new firmware. Therefore, an attacker will typically try to undo any firmware updates that have been applied.

For example, an attacker can try to reflash a device with an older, more vulnerable image. When that earlier firmware image is installed, they can then exploit its known vulnerabilities to take control of the device and access sensitive data. Or an attacker could roll back some device settings to factory settings, which, once again, can have serious implications.

Anti-rollback is designed to prevent attacks like these from happening by making sure earlier versions of the firmware cannot be loaded by people with malicious intent. Similarly, it can be used to protect critical parameters from being reverted. Rollback should be possible for recovery purposes but only if authorized. 

Anti-rollback: Aligning with Industry Best Practice

Anti-rollback is one of our PSA Certified 10 security goals. The goals highlight best practice security to help you avoid the most common mistakes, and they are a firm foundation that any connected device can be built on.

Firmware updates are covered by three of the goals: secure boot, secure update and anti-rollback. It is important to ensure updates cannot be reverted by an attacker. If a firmware update can be reversed, the device can be returned to a vulnerable state.

An increasing number of security experts share this view and are highlighting the importance of protecting a device against rollback attacks. In fact, providing appropriate safeguards may soon be required if you are operating in some of the world’s biggest markets. New security laws, regulations and baseline requirements are being introduced as governments and standards organizations respond to an increase in the number of cyberattacks. The need to keep firmware updated is already covered by the European standards organization, ETSI, in its Cyber Security for Consumer Internet of Things: Baseline Requirements (ETSI EN 303 645). The document describes secure update measures, including an anti-rollback policy to prevent downgrade attacks.

Similarly, recommendations published by the National Institute of Standards and Technology (NIST) in the US (NISTIR 8259A) describe the need for: “The ability for authorized entities to roll back updated software to a previous version.” It goes on to say: “Some organizations may want a rollback capability in case an update inadvertently impacts critical applications or integration with other systems, while other organizations may prefer to eliminate the risk of someone intentionally or inadvertently rolling software back to a vulnerable version.”

So, what does all this mean in practice?

To make securing a connected device quicker and easier, and to help you demonstrate compliance with industry standards, we introduced the PSA Certified framework and multi-level certification scheme.

PSA Certified Level 1 strongly recommends meeting the anti-rollback security goal. PSA Certified Level 1 also aligns with the baseline requirements of ETSI EN 303 645, NISTIR 8259A, and emerging regulations from the UK’s Department for Digital, Culture, Media & Sport.

Implementing the anti-rollback security goal becomes an essential requirement at PSA Certified Level 2 and PSA Certified Level 3 where the Root of Trust is penetration tested to ensure protection against specific IoT attacks.

So, let’s look at the implementation in more detail.

Implementing the Anti-rollback Security Goal

To ensure a device does not load old firmware, it needs to keep a record of the current firmware version. This is usually achieved by storing a version number. When the device turns on, it checks the version of the firmware images it loads. The version information is usually part of a signed certificate or header to detect unauthorized tampering.

If the firmware is new, the record may be updated. However, in some cases, it is reasonable to expect that the record will only be updated when the device manufacturer is confident the update has not broken the system. For example, the device might check that the firmware updates are working correctly before updating the record, or a remote device management service may securely signal to the device that the record can be updated.

If the firmware is old, the device will refuse to load it and might enter a recovery mode.

In all cases, the record must be stored in a safe place so it cannot be altered by an attacker. The PSA Certified scheme recommends the record is stored and protected by a PSA Root of Trust (PSA-RoT), which contains secrets and upholds the foundational security of each device. The particular type of storage needed for this record depends on the required level of security and manufacturing economics.

For example, if the device requires protection against firmware attacks (this is needed at PSA Certified Level 2), the following options are available:

• On-chip flash accessible only to the PSA-RoT. This is often the simplest solution, but it is not always available for system-on-chip (SoC) designs. It is ideal for protecting code and data that changes frequently over time.
• A secure area of an external flash device. This area of storage is protected by the PSA-RoT. For example, it might be an SPI flash that is locked during the device boot, or it may be flash that is mediated by a trusted PSA-RoT service.
• Cloud-based storage. The PSA-RoT must create a secure connection to the cloud. However, since this requires good connectivity, cloud uptime and complex security, it may not be practical for most deployments.  

For protection against firmware and physical attacks, as required by PSA Certified Level 3, we could consider the following solutions:

• On-chip flash accessible only to the PSA-RoT. Again, this is a simple solution but one that may not be available for SoC designs.

• On-chip One Time Programmable memory is a viable solution at all certification levels (although it is not required at Levels 1 and 2) and can be used as a counter, where individual bits can be programmed over time, for example, using anti-fuse or eFuse technology. The SoC manufacturer should include enough bits to last the number of updates expected over the supported lifetime of the PSA-RoT. This technology is ideal for checking the version of the PSA-RoT, as it is not expected to have many firmware updates over time.

• Secure Elements (SE) can provide counters to the PSA-RoT. As an SE is a peripheral, a physical attacker has more opportunities to tamper with the connection. To counteract this, many SEs support a cryptographically protected channel between the host chip and the SE, typically using secrets provisioned in the factory. If these secrets are provisioned, the host chip and the SE can communicate securely for the product lifetime.

• Secure flash products are a special type of flash that supports encryption and replay protection. However, the device is a peripheral, so a physical attacker could tamper with the connection. The secure flash product must support a secure channel between the host chip and the flash device, typically using secrets provisioned in the factory. When these secrets are provisioned, the host chip and secure flash can communicate securely for the product lifetime. In particular, a secure flash product with a Replay-Protected Monotonic Counter (RPMC) counter or an eMMC flash product with a Replay-Protected Memory Block (RPMB) are good solutions.

Anti-rollback ensures that earlier versions of firmware cannot be reinstated and used maliciously. As a key security function, it is one of the PSA Certified 10 Security Goals, that outline common requirements that should be implemented into every connected device. Critical security principles, such as anti-rollback, provide a baseline to protect against rising hacks and align with industry best practice. Anti-rollback is strongly recommended for PSA Certified Level 1. When looking for protection from software and hardware attacks, anti-rollback becomes increasingly important and is, therefore, an essential requirement for PSA Certified Level 2 and PSA Certified Level 3. More information on anti-rollback can be found in the PSA Certified Protection Profiles which outline the base security requirements that the evaluation laboratories will test at each level.