WEBVTT 00:00.000 --> 00:13.440 Hello everybody here at the Lightning Talks at Boston here in Brussels, I want to introduce 00:13.440 --> 00:20.920 to you Raphael Woodwell, with a very interesting topic about securing downloads from the internet, 00:20.920 --> 00:25.160 give him a warm welcome and have fun with his talk. 00:25.240 --> 00:31.080 Thank you. 00:31.080 --> 00:38.880 The time starts now, so be ready to listen to me for 15 minutes, about security, a very 00:38.880 --> 00:46.520 sexy subject, because I'm talking about as fellow the project I've been working on, 00:46.520 --> 00:50.480 which aims to secure downloads from the internet. 00:50.480 --> 00:57.480 Today we have a lot of software and packages available directly, available for download 00:57.480 --> 01:03.680 from the internet, from GitHub releases, Docker images, etc. 01:03.680 --> 01:08.960 The problem is that often it is not possible to check the authenticity of the file 01:08.960 --> 01:19.200 you download, so you hope something the file you download is real, is legit, but how do 01:19.200 --> 01:27.200 you verify it, because checks are not checking the authenticity of the file, it's validating 01:27.200 --> 01:31.760 the integrity of the file you download. 01:31.760 --> 01:40.840 And the wood course I think is that there is no very easy system to check file signatures. 01:40.840 --> 01:49.160 We all know GPG, but it's a cumbersome system to use, few people use it actually, 01:49.160 --> 01:56.560 and the key management is probably also a stumbling block. 01:56.560 --> 02:03.280 As I said, checksums are not sufficient for authenticity checks, they can only ensure integrity. 02:03.280 --> 02:08.800 There is absolutely no security benefits to check the checksum of the file, if the checksum 02:08.800 --> 02:14.680 comes from the same source as the file. 02:14.680 --> 02:22.000 So as far though, it's proposing an easy-to-use, multi-segnature system for file authentication. 02:22.000 --> 02:27.560 We want to be very easy to use, in a sense that if you want to download the file, you 02:27.560 --> 02:30.400 just have to provide the URL of the file. 02:30.400 --> 02:37.280 You don't have to provide a key bundle, you don't have to download the public key from 02:37.280 --> 02:43.440 the user, we want to automate all this. 02:43.440 --> 02:50.120 The adding of design decisions is that we want to use as much as possible existing building blocks. 02:50.120 --> 02:53.280 We don't want to invent the wheel. 02:53.280 --> 02:56.280 So we are using Git as the data store. 02:56.280 --> 03:04.760 We are using mini-sign, which is a signature system based on signify from OpenBSD. 03:04.760 --> 03:12.120 And we will sign the checksums file as a lot of projects already published checksums. 03:12.120 --> 03:18.040 So we hope those projects will join us in signing their checksum files. 03:18.040 --> 03:22.160 We are meeting an app on the mirror of checksum files. 03:22.160 --> 03:26.800 This is a Git repository that is absolutely auditable. 03:26.800 --> 03:33.600 And it's an app on this, so no commit is ever amended. 03:33.600 --> 03:37.760 And you can check that because it's a Git repository, you can clone it, you can download 03:37.760 --> 03:39.240 it, you can sync it. 03:39.240 --> 03:45.000 And if a commit was modified, you can absolutely detect it. 03:45.000 --> 03:49.720 The advantage of this mirror is that even without signature, it can increase the security 03:49.720 --> 03:52.920 of downloading file from the internet. 03:52.920 --> 03:59.000 Because we have a checksum that is available from an Edip and then source from the 03:59.000 --> 04:00.560 don't know the file. 04:00.560 --> 04:09.720 So if the publishing repository is compromised, it would take to compromise our mirror 04:09.720 --> 04:15.360 for downloaders to not detect it that they have a malicious file. 04:15.360 --> 04:23.080 So even without signature, we try to already increase the security for the users. 04:23.080 --> 04:27.840 Another key decision is that we authenticate at the repository level. 04:27.840 --> 04:30.400 We don't authenticate the developer itself. 04:30.400 --> 04:34.280 We authenticate the publishing platform. 04:34.280 --> 04:38.960 This is an inspiration form, let's say, quick, which will validate that someone 04:38.960 --> 04:42.960 controls the domain name system at DNS. 04:42.960 --> 04:50.160 And we will validate that someone controls a publishing accounts. 04:50.160 --> 04:56.000 And we don't check the identity of the user itself. 04:56.000 --> 05:00.080 We introduce an easy-to-use multi-signature system. 05:00.080 --> 05:06.960 Multi-signature means that for a file published files to be authenticated as valid, it requires 05:06.960 --> 05:08.560 multiple signatures. 05:08.560 --> 05:12.240 So signature for multiple users. 05:12.240 --> 05:18.400 Taking this approach also helps in the case the publisher account is breached. 05:18.400 --> 05:24.520 As multiple signatures are needed, even if one of the user accounts is breached, we can 05:24.520 --> 05:30.040 still contain the problem. 05:30.040 --> 05:32.880 We want to be publication platform agnostic. 05:32.880 --> 05:40.080 So we want to support a lot of publication platforms, but we start small and we start 05:40.080 --> 05:42.880 by supporting GitHub for the moment. 05:42.880 --> 05:46.600 But this is absolutely not a limitation that we will keep. 05:46.640 --> 05:55.440 We want to expand to other platforms and even for self-hosted systems. 05:55.440 --> 06:03.880 Regarding our as-valued mirror, it's an important part in our solution. 06:03.880 --> 06:12.040 And it's a critical component, and you will trust as-valued if you trust that our mirror 06:12.040 --> 06:14.080 is safe and secure. 06:14.160 --> 06:18.720 That's why we want to be absolutely transparent about our mirror. 06:18.720 --> 06:21.720 It's a git repository published on GitHub. 06:21.720 --> 06:23.920 You see the URL there. 06:23.920 --> 06:27.400 And you can follow it. 06:27.400 --> 06:29.200 You can follow the evolution. 06:29.200 --> 06:37.520 What happens to the git to the mirror is that when a git project publishes a release, 06:37.520 --> 06:45.040 we, if we follow it, we will synchronize the checksums from the release in our mirror. 06:45.040 --> 06:52.640 If we don't follow it, or if you want your project to be included in the mirror, very rapidly, 06:52.640 --> 06:56.440 we encourage you to use our notification system. 06:56.440 --> 07:04.560 So that we immediately mirror your checksums in our repository. 07:04.560 --> 07:06.880 So that you can trust the mirror. 07:06.880 --> 07:09.360 We have a mirror checker. 07:09.360 --> 07:16.800 Those are simple scripts that will check that there is no comment that was a minute. 07:16.800 --> 07:21.320 So it's check that it can do a fast forward. 07:21.320 --> 07:28.360 And it will also validate that every commit includes checksums that are identical to the 07:28.360 --> 07:31.680 one found in the release. 07:31.680 --> 07:38.480 This should give trust in the mirror that we provide the right data, and that it was 07:38.480 --> 07:42.240 not compromised. 07:42.240 --> 07:50.600 Regarding the workflows, we, we take the approach of trusting at first use. 07:50.600 --> 07:57.160 If you have a better suggestion, I'm open to it, but we take the same approach as 07:57.240 --> 08:03.480 let's encrypt, which trusts that people controlling a DNS entry or legit. 08:03.480 --> 08:11.840 We take the same approach, and so people that want to start signing packages will put 08:11.840 --> 08:19.720 a sinus file in their repository at the root directory. 08:19.720 --> 08:22.960 This is an example. 08:22.960 --> 08:32.240 This file defines three sign-ups with the format mini-sign, and we include the public key for 08:32.240 --> 08:33.240 each sign-up. 08:33.240 --> 08:40.600 You see the public key is short, so it can easily be shared in a QR code or on a website, 08:40.600 --> 08:42.080 etc. 08:42.080 --> 08:45.520 And you see that there is a threshold above of two. 08:45.520 --> 08:59.840 So this means that every release will require two signatures from the sign-ups to be accepted. 08:59.840 --> 09:06.560 When a release is published, it needs to have a checksum file in it for integration with 09:06.560 --> 09:13.280 the as-valued, the checksums on mirrors, and at that time we start collecting signatures 09:13.320 --> 09:18.880 from sign-ups that were mentioned in the repository. 09:18.880 --> 09:24.840 The signatures will be added in the mirror, and sign-ups will get a notification. 09:24.840 --> 09:29.000 That's something we need to provide, a notification. 09:29.000 --> 09:33.680 That's a new release is waiting a signature for them. 09:33.680 --> 09:37.080 If this signature is legit, they can sign it. 09:37.080 --> 09:42.680 If not, they can still stop the process and not sign it. 09:42.680 --> 09:49.160 So that further downloads will detect it was not signed correctly. 09:49.160 --> 09:56.120 We will provide tools to facilitate this, but actually as it is a good repository, it could 09:56.120 --> 09:59.760 also be done with the simple pull request. 09:59.760 --> 10:05.960 So it's a really basic system, totally transparent using standard solutions. 10:05.960 --> 10:14.600 We don't invent a lot of things, we just put the glue between existing building blocks. 10:14.600 --> 10:22.160 When downloading a file, the easiest will be to use our tool, which we call as-valued. 10:22.160 --> 10:27.240 It doesn't take signatures for the moment, it's coming soon, but it's already used 10:27.240 --> 10:30.280 the mirror, the checksum mirror. 10:30.280 --> 10:36.800 So when you want to download with Asphalt, you just provide the URL of the file to download, 10:36.800 --> 10:43.520 and it's Asphalt that will take a look on the mirror to find the checksums. 10:43.520 --> 10:45.720 And it will also compare to the release. 10:45.720 --> 10:54.520 So there is a double check on the mirror and in the release to see if the checksum is correct. 10:54.520 --> 10:57.800 And below, you have a screenshot of the output. 10:57.800 --> 11:02.080 So the working will be the same with signatures. 11:02.080 --> 11:10.320 It will just check the signature in addition to the checksums as it does now. 11:10.320 --> 11:18.360 The thing signers will require that the existing signers sign the change, and we need to also 11:18.360 --> 11:23.560 check that the new signers have the public key that is mentioned, so they also have to sign 11:23.560 --> 11:29.560 the change. 11:29.560 --> 11:35.280 Regarding the implementation, we have the checksums mirror that is fully operational, 11:35.280 --> 11:43.640 so we have a subscribed to a lot of repositories on GitHub, and we follow the releases. 11:43.640 --> 11:51.000 There is a small delay between the release and the time we make the mirror of the checksum files. 11:51.000 --> 11:55.600 And if you want to shorten that delay, you can notify us. 11:55.600 --> 12:01.800 We have GitHub actions to notify our backlands to integrate your checksums immediately. 12:01.800 --> 12:06.800 The download tool is available as fast. 12:06.800 --> 12:15.600 Everything is open source, of course, and the signatures are in developments, and we are looking 12:15.600 --> 12:23.120 for testers, and people that are interested to suggest improvements, so be sure to contact 12:23.120 --> 12:24.120 us. 12:24.120 --> 12:31.720 You have the contact information here, our website, our GitHub repository, the spec repository 12:31.720 --> 12:38.440 is where we take note of the specifications of how we work, how we add signatures, how 12:38.440 --> 12:43.920 we check signatures, where they are stored, etc. 12:43.920 --> 12:45.920 And we are also on Amazon. 12:45.920 --> 12:47.240 So thank you for attention. 12:47.240 --> 12:53.520 I hope you get interested in the passwords and be sure to contact us if that's the case. 12:53.520 --> 12:54.520 Thank you very much. 12:54.520 --> 12:59.520 Thank you for your time. 12:59.520 --> 13:00.520 Thank you.