Software Supply Chain Security
Verifiable Updates and Rollback Protection for Black Wall
Research ID: secure-os-updates
Design an update architecture that verifies authenticity, resists unauthorised modification, recovers safely from interrupted installs and restricts unauthorised downgrades.
Problem statement
Investigate an update architecture that verifies authenticity, prevents unauthorized modification, supports safe recovery from interrupted updates, and restricts unauthorized downgrades.
Why it matters
The update path is a direct route to every deployed system, and an interrupted or forged update can leave a device unbootable or permanently behind on fixes. Integrity, recovery and rollback policy have to be designed together.
Research questions
- 01 What must a signed update manifest cover so that the payload cannot be substituted or mixed across versions?
- 02 How should atomic updates and A/B partitions behave when power is lost mid-installation?
- 03 Which compatibility checks are needed before an update is allowed to replace a working system?
- 04 How can legitimate recovery downgrades be distinguished from unauthorised rollback attacks?
Research objectives
- Design signed update manifests.
- Investigate atomic updates and A/B system partitions.
- Validate update compatibility and integrity.
- Test interrupted installation and recovery.
- Develop a rollback policy that preserves legitimate recovery options.
Technical challenges
- Power loss can occur at any point in the write, verification or boot-selection sequence.
- A/B partitioning consumes storage and requires a reliable selection mechanism.
- Rollback protection must still permit recovery from a genuinely bad release.
- Update metadata and the update client are themselves part of the trusted computing base.
Expected outcome
A secure-update prototype with integrity checks and reproducible recovery tests.
Tags
Related research
Work on this problem
Apply to the lab and this problem becomes your supervised research project.