Search for: All records

Computing and networking are increasingly implemented in software. We design and build a software build assurance scheme detecting if there have been injections or modifications in the various steps in the software supply chain, including the source code, compiling, and distribution. Building on the reproducible build and software bill of materials (SBOM), our work is distinguished from previous research in assuring multiple software artifacts across the software supply chain. Reproducible build, in particular, enables our scheme, as our scheme requires the software materials/artifacts to be consistent across machines with the same operating system/specifications. Furthermore, we use blockchain to deliver the proof reference, which enables our scheme to be distributed so that the assurance beneficiary and verifier are the same, i.e., the node downloading the software verifies its own materials, artifacts, and outputs. Blockchain also significantly improves the assurance efficiency. We first describe and explain our scheme using abstraction and then implement our scheme to assure Ethereum as the target software to provide concrete proof-of-concept implementation, validation, and experimental analyses. Our scheme enables more significant performance gains than relying on a centralized server thanks to the use of blockchain (e.g., two to three orders of magnitude quicker in verification) and adds small overheads (e.g., generating and verifying proof have an overhead of approximately one second, which is two orders of magnitude smaller than the software download or build processes). 

Domain Name System Security Extensions (DNSSEC) uses public-key digital signatures to provide integrity and authentication for DNS query responses. The current standardized DNS for reliable UDP delivery limits DNS response (including the message, signature, and public key) to a maximum of 1232 bytes. Incorporating NIST’s post-quantum digital signatures into the DNS protocol results in a response size that exceeds the limit set by the Ethernet standardization, making PQC incompatible with the current standardized DNS. To address the incompatibility and enable PQC to protect the authenticity against the quantum-equipped adversaries, previous research proposed fragmenting the DNSSEC messages. Fragmentation however exposes DNSSEC to Fragmentation Mis-Association threat, traditionally studied in the broader IP fragmentation contexts and not applicable in the current DNSSEC with classical/pre-quantum cipher (no fragmentation needed). We distinguish our work from the previous research incorporating PQC to DNSSEC to defend against the Fragmentation Mis- Association Threat by chaining the fragments and applying cryptographic commit-and-reveal. We also advance the previous research and further reduce the number of packet fragments, which can be particularly useful as the DNSSEC based on UDP is prone to packet transmission failure increasing the chance of the DNS response failure when sent in multiple fragments, by using blockchain to offload and enable the offline delivery of the public key. Our scheme thus even allows the Falcon-512 PQC cipher incorporation to forgo the fragmentation, in contrast to the previous research requiring fragmentation for Falcon-512; the other PQC ciphers, i.e., Dilithium ciphers and Falcon-1024, still require fragmentation in our scheme due to the standardized signature sizes. We implement our scheme and analyze the effectiveness and performances through experimentation. 

Cryptocurrency is designed for anonymous financial transactions to avoid centralized control, censorship, and regulations. To protect anonymity in the underlying P2P networking, Bitcoin adopts and supports anonymous routing of Tor, I2P, and CJDNS. We analyze the networking performances of these anonymous routing with the focus on their impacts on the blockchain consensus protocol. Compared to non-anonymous routing, anonymous routing adds inherent-by-design latency performance costs due to the additions of the artificial P2P relays. However, we discover that the lack of ecosystem plays an even bigger factor in the performances of the anonymous routing for cryptocurrency blockchain. I2P and CJDNS, both advancing the anonymous routing beyond Tor, in particular lack the ecosystem of sizable networking-peer participation. I2P and CJDNS thus result in the Bitcoin experiencing networking partitioning, which has traditionally been researched and studied in cryptocurrency/blockchain security. We focus on I2P and Tor and compare them with the non-anonymous routing because CJDNS has no active public peers resulting in no connectivity. Tor results in slow propagation while I2P yields soft partition, which is a partition effect long enough to have a substantial impact in the PoW mining. To better study and identify the latency and the ecosystem factors of the cryptocurrency networking and consensus costs, we study the behaviors both in the connection manager (directly involved in the P2P networking) and the address manager (informing the connection manager of the peer selections on the backend). This paper presents our analyses results to inform the state of cryptocurrency blockchain with anonymous routing and discusses future work directions and recommendations to resolve the performance and partition issues.