Prometh

Two critical challenges arise when we interact with a software system: whether the software implements correct behaviours, and whether the software’s behaviours are correctly enforced. The second challenge is addressed by the Leviatom Network, which identifies and immediately eliminates the nodes who execute the wrong software or load the wrong components to support the given software. Leviatom also provides the “Conspiracy Breaching” value to indicate the trustworthiness of the selected node. This gives the MarCarta Contract a reference for determining the consensus strategy.

The first challenge is addressed by the Prometh framework. It aims at identifying the fault behaviours embed inside the software itself. To ensure a piece of software to only carry expected behaviours, all the procedures of its full lifecycle should be considered. Especially the most critical ones as:

1. During development, the source codes of the target software may be tampered with to include malicious behaviours. Backdoor codes might be inserted into the source codes and remain hidden. Unintended or deliberately software bugs may also exist, which will result in targeted 0-day exploits to get instantiated;

2. During building and packaging procedures, malicious binary codes may be injected into the correctly compiled object files. This might be caused by a fault complier which generates malicious codes. It might also be caused by a fault linker which substitutes the correct object files with malicious ones. The host operating system might also substitute the object files at the filesystem level.

3. During the delivery and installation, the binary codes of the target software might be substituted or patched with malicious codes. This might occur during the transmission of the software package. During installation, the extracted binary codes or configuration files might also be changed maliciously.

Prometh solves the software security issues by firstly recording the critical information (or its undeniable identification) of all the critical steps of a software’s full life-cycle on a distributed ledger. It then encourages a community to iteratively evaluate whether each step is correctly executed. Security verification methods will also be enforced on the artefacts produced by each procedure, such as the source codes, object files, binary files, package files, etc. These methods will iteratively dig the security and functional implications from the artefacts, generating a clearer profile for a target application. The following figure depicts the general procedures:

The trusted building process starts when the developers pushed source codes to the repositories. Even though the development environment is untrusted, the integrity of the entire process is not affected, as the resulting source codes are easily audited and verified. Once the source codes are pushed, their identification data will be recorded on the distributed ledger. The security analytics procedure, running on Leviatom, will be triggered to fetch the source codes and run the verifications. Once the verification passes, the results are stored on the ledger, and the next procedure is triggered. The resulting identifications of the binary codes are pushed to the ledger, and the analytics process are invoked to examine the integrity of the compiling and linking procedures.

With this iterative procedure, Prometh ultimately creates a decentralised traceable software lifecycle, which allows users to interrogate the origin of any piece of software and examine their functional and security implications. Prometh’s core is a Trusted Building System (TBS) which implements a set of trusted transformation process. Its design and implementation are backed by Trias founding team’s research in the System Security group at Peking University since 2009 [4,5,6].

More details in design and implementations of Prometh and the TBS will be illustrated in a dedicated technical whitepaper.