How System76 Uses Blockchain to Deliver Firmware Updates
The latest blockchain success stories pulsing throughout the media have largely surrounded its application in decentralized currency. But three engineers at System76 have found another use for blockchain that they hope will become a trend for more essential reasons: eliminating security vulnerabilities in computers relating to firmware updates.
In this blockchain system, firmware updates are delivered using a build server, which contains the new firmware, and a signing server, which verifies that the new firmware came from inside the company. The two servers are only connected via a serial cable. The lack of a network between the two means that one server cannot be accessed if entry is achieved through the other server.
Multiple build servers are set up alongside the primary build server. In order for a firmware update to receive a signature of verification, the firmware updates must be identical on all build servers. If even one build server contains a compromised firmware update, this update cannot proceed to signing and will not be delivered to our customers.
Firmware updates are often overlooked as a potential security vulnerability. We found that other vendors would use https without signing their updates, or that they would sign updates but only use http. With this oversight, an attacker could potentially duplicate the vendor’s website while pushing an older firmware update to the user that contains a vulnerability, and then exploit that vulnerability in the older version.
Using blockchain to distribute updates removes the threat of this kind of attack. Each version of signed firmware is kept as a block that is only viewable in a ledger. Only the most current firmware update in the chain can be sent to customers, ensuring that only new updates can be implemented.
The signing server adds an extra layer of complexity to the blockchain method. The signing key is kept in the server’s memory, so it can only be obtained when the server is on. Not to mention, an attacker would also have to create false firmware in every build server at the same time, which makes it highly improbable for a successful attack to occur.
In the event one does occur, the way to stop it would be to simply unplug the signing server or one of the build servers. Once that happens, the false firmware would be rejected by the system and archived as an old update, rendering that version inaccessible by the attacker.
The blockchain method of delivering firmware updates took a team of three engineers only a couple weeks to develop, but it has removed almost all existing vulnerabilities from the current system. In the near future, we hope to see other vendors follow suit in maintaining a secure environment for their users.
As we transition to coreboot, buildchain will provide guarantees of source to firmware that can be verified by users building the same firmware on their own.
