Skip to content

Latest commit

 

History

History
94 lines (52 loc) · 7.18 KB

code-and-file-signing.adoc

File metadata and controls

94 lines (52 loc) · 7.18 KB
Raw

Blockchain-based Trust for Software Components

Zooko’s Triangle Stalks the Bazaar

A computing device cannot be secure if an attacker is able to surreptitiously insert malicious code on it. Current solutions for signing and verifying computer software — both source code and binaries — generally rely on the same flawed, hierarchical systems as our network connections do.

Blockchain technology allows us to sidestep Zooko’s Triangle [zooko] and provide systems of identification that are decentralized, secure, and human-meaningful. Today’s dominant code signing and verification technologies rely on centralized certificate authorities and/or centralized hardware or operating system vendors. These solutions are typically oriented toward end-user installation of applications and do not address the needs of software developers who increasingly rely on externally developed components in both source and binary form. Open Source Software has moved us in the direction of the Bazaar [catb] and created an incredibly powerful and diverse supply chain, but has brought with it new risks.

Language-specific software component repositories such as Maven, NPM, RubyGems, and CocoaPods are not as secure as they should be and yet most developers have no alternative but to assume their component downloads have not been tampered with. In the rare circumstances where developers are validating their downloaded components they’re using homegrown validation tools and often manually verifying hashes. Typically file hashes are stored on the same server as the hashed file to be validated. If the download is compromised, the hash will be too. Developers need a way of sending and receiving decentralized, secure, and human meaningful information that can be used to secure software components and applications.

Blockchain-based ID Systems Can Help

As blockchain-based identity solutions become increasingly viable and search for early adopters, they can be applied to the software development process itself.

Namecoin is (one of?) the first blockchain-based identity solutions and currently provides enough functionality to solve some of the major issues involved in secure software distribution. Blockchain-agnostic middleware like DNSChain [dnschain] can provide servers and APIs for integrating with software build tools to provide the decentralized identity and other functions that are needed. Developing tools that are blockchain-agnostic will reassure tool developers that they can migrate to another blockchain based upon future adoption and technology trends.

One area of concern is "blockchain bloat", but it is unclear whether file signatures would be stored on a blockchain and, if so, how many would really need to be store. There has been preliminary discussion within the Namecoin community about blockchain-based signing/hashing of file contents although simply using a blockchain user id or domain id may be enough to significantly improve some of the current pain points.

Proposed directions

We propose discussing these issues at the conference and unless presented with more attractive options, proceed with developing a working prototype for the Java ecosystem that uses Namecoin and DNSChain. Why Java? It is large, it generally distributes binaries rather than sources, it is clearly in need of solution, and (this author) knows it best.

Java & Maven Repositories

For years the default option for the leading Java repository, Maven Central, was to use HTTP rather than HTTPS. This weakness was common knowledge, but generally ignored. In 2014 an exploit was demonstrated [veytsman] that used a MITM attack to insert unwanted code into any downloaded JAR file. Shortly thereafter https became the default option. However, there are still no reliable, automated methods for ensuring that files weren’t corrupted on the Maven Central servers themselves [jbaruch1]. JCenter provides additional identity information about component developers but does not provide a truly decentralized solution [jbaruch2].

Maven is the build tool that standardized the Maven repository format. Currently the Maven Enforcer Plugin and the BitcoinJEnforcerRules Plugin are available for validating file hashes [bitcoinj]. Gradle is a newer build-tool that has been gaining in popularity and is now the standard build tool for the Android platform. The Gradle Witness Plugin seems to be the best (only) choice for validating downloads.

Given the author’s preference for and familiarity with Gradle, it is likely that the Gradle Witness Plugin will be the starting point for the project.

Issues

The issues are grouped into short-term (roughly corresponding with the coming "Rebooting the Web of Trust Hackathon") and longer-term issues.

Short-term

  • It looks like Namecoin is going to be the first implementation, but feedback is welcome.

  • Which namespaces will be used? d/, id/, or both?

  • Integration with Gradle and Maven build tools (most likely via plugins)

  • Focus on new releases that can use new methods and tools

  • Other languages welcome if Hackathon volunteers.

Longer-term

  • How to validate older, existing releases.

  • Tools for languages and repositories other than Java

  • How to handle name expiration

  • Solutions for blockchains other than Namecoin

  • Hierarchical authority and delegation for larger organizations

  • Multi-signature key management (both blockchain address and code signing key)

  • Code-signing certificate issuance and revocation

Appendix: Language-Specific Tools & Software Repositories

This section will be updated as we collect additional information on the tools and repositories of other languages.

Ruby

JavaScript (Node.js)

Early work on using hashes for validation of scripts loaded from CDNs: https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/

Objective-C/Swift

Bibliography