Bootstrapping Trust in Community Repository Projects

Abstract

Community repositories such as PyPI and NPM are immensely popular and collectively serve more than a billion packages per day. However, existing software certification mechanisms such as code signing, which seeks to provide to end users authenticity and integrity for a piece of software, are not suitable for community repositories and are not used in this context. This is very concerning, given the recent increase in the frequency and variety of attacks against community repositories. In this work, we propose a different approach for certifying the validity of software projects hosted on community repositories. We design and implement a Software Certification Service (SCS) that receives certification requests from a project owner for a specific project and then issues a project certificate once the project owner successfully completes a protocol for proving ownership of the project. The proposed certification protocol is inspired from the highly-successful ACME protocol used by Let’s Encrypt and can be fully automated on the SCS side. It is, however, fundamentally different in its attack mitigation capabilities and in how ownership is proven. It is also compatible with existing community repositories such as PyPI, RubyGems, or NPM, without requiring changes to these repositories. To support this claim, we instantiate the proposed certification service with several practical deployments.

A Security Analysis

We now turn to analyzing the security of the proposed SCS protocol. We first show that the protocol meets the security goals stated in Sect. 4.2, and then analyze the protocol’s compromise resiliency.

SG1: Only a project’s owner should be able to complete the certification for that project. To prove ownership over a project, which is required for completing the certification protocol, an entity must successfully complete the challenges generated by the SCS server. As such, for each challenge, the entity must both:

• Hold the private key of the SCS account key pair used to respond to the challenge. This is because the responses from the client to the SCS server must be signed with that key.

• Control the project in question. This is because successfully provisioning the challenge response on the project’s homepage requires write-access to the project’s repository.

Since only the project owner has write-access to the project’s repository, a successful execution of the SCS protocol ensures that a specific SCS account holder is also the entity that controls a project (i.e., the project owner).

SG2: Messages generated during one execution of the certification protocol for one account (i.e., between the SCS server and one client) cannot be used towards obtaining authorizations for other accounts. This is achieved because all messages sent by an SCS client to the SCS server are signed using that client’s SCS account private key. Thus, such messages cannot be reused between instances of the certification protocol executed by different SCS account holders.

SG3: Attackers that gain control over a project’s repository for a short period of time are not be able to successfully complete the SCS certification protocol. The certification protocol is designed so that the identifier authorization step lasts over an extended period of time. An entity attempting to complete the certification protocol for a project must complete multiple challenges. For each challenge, the challenge response must be maintained persistently on the project’s homepage, because the SCS server will check multiple times randomly during the challenge validation window. If an attacker is able to briefly gain control over the project’s repository, she maybe able to provision a valid challenge response for that challenge. However, such an attacker will not be able to successfully provision valid information for subsequent challenges.

SG4: We need to show that an attacker cannot complete an SCS certification for a project in a stealthy manner. The SCS protocol achieves this by requiring that all challenge responses must be placed on the project’s repository in a publicly visible way (i.e., on the project’s homepage). This ensures that the legitimate project owner and/or other project maintainers will notice that a certification protocol is ongoing.

Compromise Resiliency. If an attacker is able to get hold of the repository key for a project, this allows the attacker unfettered access to the project repository, including making changes to the project’s homepage. The attacker can register an account with the SCS server and then request a project certificate under this SCS account. Having access to the repository key, the attacker will be able to provision challenge responses on the project homepage.

The SCS protocol has two safeguards in place to deal with a repository key compromise. First, the certification protocol is designed to to last over an extended period of time. Thus, if the repository key compromise is detected early enough, the project owner can change the repository key, preventing the attacker from successfully completing the certification protocol. In this way, a successful attacker would have to maintain control over the project repository for a longer period of time, which is arguably more difficult to achieve while going undetected. Second, the SCS protocol requires that the response to a challenge must be placed on the project’s repository in a publicly visible way (i.e., the project’s homepage). This will prevent an adversary to execute the certification protocol stealthily, as the legitimate project owner and/or other project maintainers will notice that a certification protocol is ongoing and will take steps to terminate such an active threat.