# Distributed Software Build Assurance for Software Supply Chain Integrity
## 4 Our Scheme
### Blockchain for Authority: Reference Distribution in Offline and Access in Online  
We use blockchain to serve as the authority to provide the reference information to enable the online user-side verification, in contrast to the centralized server approach implementing the logical authority on a physical remote server machine, as described in Section 4.2. In addition to having high payload integrity (cannot change or modify the payload content on the blockchain ledger) and high visibility and accountability (thanks to the distributed storage and easy read-access), we apply blockchain to implement the authority because blockchain supports automatic broadcasting and distributed storage to distribute the proof offline.  
In our scheme, blockchain enables the reference proof to be distributed to the prospective downloading users offline (i.e., any time before the software download, build, and the build assurance verification). The networking and sharing of the proof reference information of \(p^{\prime}\) (\(s^{\prime},b^{\prime},d^{\prime}\) are used to compute \(p^{\prime}\) but do not get networked) are offline so that they are stored within the user machine before the software download and build. In online, i.e., when downloading and building the software, the user simply accesses the blockchain database stored within its machine (computing only). In contrast, the centralized server approach involves the \(p^{\prime}\) delivery and networking online (networking and computing). Because the networking and distribution of the reference information of \(p^{\prime}\) are offloaded to before the software download/build, our scheme is significantly more efficient than the  
Figure 4: Merkle tree application for our scheme, where \(F_{i}\) are the source code \(s\) files and the Root is the proof \(p\).  
centralized server approach. without the explicit networking with another node, as this information is already stored in the local database provided by the blockchain.  
We build the authority using a permissioned blockchain, which controls the entities who can write on the blockchain and require registration. These entities generate the references \(s^{\prime},b^{\prime},d^{\prime},p^{\prime}\) and distribute them to write on the blockchain database, the database being locally stored and distributed to many other nodes. The entities can vary, including the software developers who write/commit/upload on the repositories or a third-party entity dedicated for software build assurance, in our scheme implementation. blockchain monitors and tracks the \(s^{\prime},b^{\prime},d^{\prime},p^{\prime}\) for accountability, so such entity control can be dynamic, i.e., an entity can be revoked. In our work, we focus on the scheme framework itself as opposed to making strong recommendations about the ecosystem when implementing our scheme framework, including who can generate the blockchain payloads and who has the write-access on the blockchain and the trade-off analyses (e.g., third-party entity outside of the developers themselves or the source-code repository can provide the separation, which can be useful in some software applications). While our scheme supports different ecosystem models and can support various entities who can contribute to writing/uploading \(s^{\prime},b^{\prime},d^{\prime},p^{\prime}\), in our concrete implementation instance in Section 5, we introduce a third-party entity to write and upload the \(s^{\prime},b^{\prime},d^{\prime},p^{\prime}\) on the blockchain data. Because of the permissioned blockchain, we use proof-of-authority for our consensus protocol, which is significantly more efficient and transaction-scalable (generating more transactions) than the permissionless blockchains, such as those for cryptocurrency (e.g., Bitcoin and Ethereum).