Hello everybody here at the Lightning Talks at Boston here in Brussels, I want to introduce
to you Raphael Woodwell, with a very interesting topic about securing downloads from the internet,
give him a warm welcome and have fun with his talk.
Thank you.
The time starts now, so be ready to listen to me for 15 minutes, about security, a very
sexy subject, because I'm talking about as fellow the project I've been working on,
which aims to secure downloads from the internet.
Today we have a lot of software and packages available directly, available for download
from the internet, from GitHub releases, Docker images, etc.
The problem is that often it is not possible to check the authenticity of the file
you download, so you hope something the file you download is real, is legit, but how do
you verify it, because checks are not checking the authenticity of the file, it's validating
the integrity of the file you download.
And the wood course I think is that there is no very easy system to check file signatures.
We all know GPG, but it's a cumbersome system to use, few people use it actually,
and the key management is probably also a stumbling block.
As I said, checksums are not sufficient for authenticity checks, they can only ensure integrity.
There is absolutely no security benefits to check the checksum of the file, if the checksum
comes from the same source as the file.
So as far though, it's proposing an easy-to-use, multi-segnature system for file authentication.
We want to be very easy to use, in a sense that if you want to download the file, you
just have to provide the URL of the file.
You don't have to provide a key bundle, you don't have to download the public key from
the user, we want to automate all this.
The adding of design decisions is that we want to use as much as possible existing building blocks.
We don't want to invent the wheel.
So we are using Git as the data store.
We are using mini-sign, which is a signature system based on signify from OpenBSD.
And we will sign the checksums file as a lot of projects already published checksums.
So we hope those projects will join us in signing their checksum files.
We are meeting an app on the mirror of checksum files.
This is a Git repository that is absolutely auditable.
And it's an app on this, so no commit is ever amended.
And you can check that because it's a Git repository, you can clone it, you can download
it, you can sync it.
And if a commit was modified, you can absolutely detect it.
The advantage of this mirror is that even without signature, it can increase the security
of downloading file from the internet.
Because we have a checksum that is available from an Edip and then source from the
don't know the file.
So if the publishing repository is compromised, it would take to compromise our mirror
for downloaders to not detect it that they have a malicious file.
So even without signature, we try to already increase the security for the users.
Another key decision is that we authenticate at the repository level.
We don't authenticate the developer itself.
We authenticate the publishing platform.
This is an inspiration form, let's say, quick, which will validate that someone
controls the domain name system at DNS.
And we will validate that someone controls a publishing accounts.
And we don't check the identity of the user itself.
We introduce an easy-to-use multi-signature system.
Multi-signature means that for a file published files to be authenticated as valid, it requires
multiple signatures.
So signature for multiple users.
Taking this approach also helps in the case the publisher account is breached.
As multiple signatures are needed, even if one of the user accounts is breached, we can
still contain the problem.
We want to be publication platform agnostic.
So we want to support a lot of publication platforms, but we start small and we start
by supporting GitHub for the moment.
But this is absolutely not a limitation that we will keep.
We want to expand to other platforms and even for self-hosted systems.
Regarding our as-valued mirror, it's an important part in our solution.
And it's a critical component, and you will trust as-valued if you trust that our mirror
is safe and secure.
That's why we want to be absolutely transparent about our mirror.
It's a git repository published on GitHub.
You see the URL there.
And you can follow it.
You can follow the evolution.
What happens to the git to the mirror is that when a git project publishes a release,
we, if we follow it, we will synchronize the checksums from the release in our mirror.
If we don't follow it, or if you want your project to be included in the mirror, very rapidly,
we encourage you to use our notification system.
So that we immediately mirror your checksums in our repository.
So that you can trust the mirror.
We have a mirror checker.
Those are simple scripts that will check that there is no comment that was a minute.
So it's check that it can do a fast forward.
And it will also validate that every commit includes checksums that are identical to the
one found in the release.
This should give trust in the mirror that we provide the right data, and that it was
not compromised.
Regarding the workflows, we, we take the approach of trusting at first use.
If you have a better suggestion, I'm open to it, but we take the same approach as
let's encrypt, which trusts that people controlling a DNS entry or legit.
We take the same approach, and so people that want to start signing packages will put
a sinus file in their repository at the root directory.
This is an example.
This file defines three sign-ups with the format mini-sign, and we include the public key for
each sign-up.
You see the public key is short, so it can easily be shared in a QR code or on a website,
etc.
And you see that there is a threshold above of two.
So this means that every release will require two signatures from the sign-ups to be accepted.
When a release is published, it needs to have a checksum file in it for integration with
the as-valued, the checksums on mirrors, and at that time we start collecting signatures
from sign-ups that were mentioned in the repository.
The signatures will be added in the mirror, and sign-ups will get a notification.
That's something we need to provide, a notification.
That's a new release is waiting a signature for them.
If this signature is legit, they can sign it.
If not, they can still stop the process and not sign it.
So that further downloads will detect it was not signed correctly.
We will provide tools to facilitate this, but actually as it is a good repository, it could
also be done with the simple pull request.
So it's a really basic system, totally transparent using standard solutions.
We don't invent a lot of things, we just put the glue between existing building blocks.
When downloading a file, the easiest will be to use our tool, which we call as-valued.
It doesn't take signatures for the moment, it's coming soon, but it's already used
the mirror, the checksum mirror.
So when you want to download with Asphalt, you just provide the URL of the file to download,
and it's Asphalt that will take a look on the mirror to find the checksums.
And it will also compare to the release.
So there is a double check on the mirror and in the release to see if the checksum is correct.
And below, you have a screenshot of the output.
So the working will be the same with signatures.
It will just check the signature in addition to the checksums as it does now.
The thing signers will require that the existing signers sign the change, and we need to also
check that the new signers have the public key that is mentioned, so they also have to sign
the change.
Regarding the implementation, we have the checksums mirror that is fully operational,
so we have a subscribed to a lot of repositories on GitHub, and we follow the releases.
There is a small delay between the release and the time we make the mirror of the checksum files.
And if you want to shorten that delay, you can notify us.
We have GitHub actions to notify our backlands to integrate your checksums immediately.
The download tool is available as fast.
Everything is open source, of course, and the signatures are in developments, and we are looking
for testers, and people that are interested to suggest improvements, so be sure to contact
us.
You have the contact information here, our website, our GitHub repository, the spec repository
is where we take note of the specifications of how we work, how we add signatures, how
we check signatures, where they are stored, etc.
And we are also on Amazon.
So thank you for attention.
I hope you get interested in the passwords and be sure to contact us if that's the case.
Thank you very much.
Thank you for your time.
Thank you.