A typical Asfaload introduction

When I introduce someone to Asfaload, the same questions are often asked in the same order. I figured I would transcribe such a typical discussion in a blog post.

What is Asfaload?

Asfaload it is an open source multi-signature system to authenticate digital artifacts. Being multi-signatures means that multiple individual signers have to provide their signature for an aggregate signature to be considered as complete.

How do you define such a multi-signature?

A JSON file, called the signers file, is used to define who has to provide signatures for an aggregate signature to be considered as complete. You decide who can sign and you define a threshold of the number of indivicual signatures that have to be collected before the aggregate signature is considered as complete. There is one group that must be defined. It is the artifact signers group. Other groups like for example administrators are also available.

But anyone can provide such a file!

The signers file only applies to the publishing account that made it available. This is the trust anchor for the signers file: it is made available on your publishing account and only applies to artifacts of that account. For example, for GitHub you make it available in your GitHub repository and only releases of that GitHub repository can be signed by that signers file. This is equivalent to Let’s Encrypt’s procedure to validate control of a domain name.

Once the Asfaload backend is aware of this signers file in your publishing account, it takes a copy of it and starts the procedure to activate it. A signers file is only active after all signers referenced in the file have actually signed it.

But what happens if a key is lost?

There is a procedure to update a signers file.

But an attacker could then provide a new signers file of which it controls all signers!

There are some criteria that have to be encountered before a new signers file is activated. Namely, the update must be signed by:

• Members of the administrators group of the current signers file
• Members of the administrators group of the new signers file
• All new signers introduced by the update.

So, how does the artifact signing go?

Let’s take as an example GitHub release. You notify the Asfaload backend of your new GitHub release, and it will build an index file containing the digest of all the release artifacts. It is this index file that will be signed. Once the threshold set in the artifact signers group is reached, the aggregate signature of the GitHub release is available for downloaders to be used.

How do downloaders validate with Asfaload?

The validation of a download is done exclusively based on the URL of the downloaded artifact. There is a deterministic mapping between the download URL and the path on the Asfaload backends where the signers file and signatures of the artifact can be found. We provide a small command line utility to help users validate their downloads. But it is also available as a Rust library for integration in existing tools. Downloading with validation is essentially calling our small tool and passing it the URL of the artifact you want to download. And everything is done automatically for the user. It is worth underlining that the user only has to pass the URL of the file to be downloaded for all validations to take place.

But if publishers sign with GPG they have the same result no?

The key difference is that Asfaload provides a multi-signature system. This provides an important security feature:

• If the signing key of a developer account is compromised, the attacker can’t publish signed artifacts. The attacker would have to compromise the threshold number of signing keys to be able to publish a compromised artifact undetected. For example, if the attacker compromises the workstation of a developer and get access to the github account together with the signing key, they still can’t publish compromised artifacts as other developers would be required to sign to attain the threshold of the multi signature definition.

But Asfaload adds a security risk: what if Asfaload’s backend is compromised?

If Asfaload backend is compromised but the publishing account is not, it will be detectable by downloaders because downloaders always check the signatures and signers files up to the trust anchor. this means tampered date on the backend will be detected by downloader.

Additionaly, the data stored by the asphaload backend is saved in a public Git repository. This allows anyone to detect commits ammended by an attacker.

There are plans to also cover the scenario where both the asphaload backend and the publishing accounts are compromised. This will involve multiple mirrors of the Git repository where the backend stores its data. This feature is in development and will be deployed in the coming months.

What if too many developers loose their keys?

A group of master keys can be defined in the signers file. These keys can only be used for signers files updates. It is encouraged to keep these offline and use them in last resort for a signers file update when the administrators group can’t, for example if too many administrators have lost their keys.

Ok, but you work with long-lived keys. Isn’t that a problem?

It is true that there’s a movement to short lived keys and certificates, which brings some advantages but we believe that the multi-signature character of Asfaload’s solution more than compensates. Asfaload’s choices makes it:

• easily self-hostable
• can trivially be deployed internally
• is resistant to some degree of key and account compromise
• gives the opportunity to the users to choose the degree of protection they need (by choosing the number of possible signers and the threshold of signatures required)

Looks interesting, but what if you signed an artifact by mistake?

There’s a group of keys with associated threshold to revoke signed artifact. Revocations are also cryptographically validated by downloading tool.

Who should be interested in this solution?

Everyone publishing digital artifact, from binaries to config files. Our first public use case is the authentication of artifacts downloaded from Github Releases. But as another example, if you regularly push config updates to a fleet of IoT devices, you want to be sure an attacker can’t publish a malevolent file. Asfaload can help in that case.