WEBVTT 00:00.470 --> 00:06.570 A question we need to ask is how much can we trust the operating systems and the applications that we 00:06.570 --> 00:07.370 use. 00:07.560 --> 00:14.820 Well we know with 100 percent certainty that all of them contain security vulnerabilities and Bogues 00:16.060 --> 00:21.290 one approach to avoid bugs is to create unknown complex systems. 00:21.340 --> 00:23.510 But this is feasible. 00:23.560 --> 00:29.790 In fact systems are getting more complex which is one of the reasons security is struggling to keep 00:29.790 --> 00:30.020 up. 00:30.040 --> 00:33.760 Complexity is the nemesis of security. 00:33.760 --> 00:40.660 Another approach to try and help protect us from these known vulnerabilities and Bogues is to use what 00:40.660 --> 00:44.110 is called formal methods in software engineering. 00:44.350 --> 00:47.680 Software is fundamentally a mathematical system. 00:47.920 --> 00:55.640 Therefore you can prove the correctness of a system through testing and proving properties of that system. 00:55.660 --> 01:03.460 This way you can provide complete evidence of correctness meaning no matter what inputs the system receives 01:03.520 --> 01:06.580 it will always compute the right values. 01:06.580 --> 01:07.890 This isn't a new concept. 01:07.900 --> 01:15.850 This formal process was really performed by human mathematicians which was feasible on programs with 01:15.850 --> 01:18.950 15 lines of code or so in the past. 01:19.330 --> 01:26.700 But with today's systems containing millions of lines it's impossible for a human to do. 01:26.890 --> 01:34.690 But what has happened recently is that both algorithms to proof and the computer power have improved 01:34.690 --> 01:37.990 enough of their computers can do the proofing for us. 01:38.320 --> 01:46.700 Unfortunately Currently only the most critical software goes through formal methods like air transportation 01:46.700 --> 01:48.860 or process control systems. 01:49.240 --> 01:56.350 Formal process is still too time consuming and cost prohibitive for most systems so most software testing 01:56.350 --> 02:01.900 today doesn't provide complete evidence of correctness proven mathematically. 02:01.930 --> 02:10.150 So we have to accept the risk of security vulnerabilities and Bogues and mitigate accordingly because 02:10.150 --> 02:17.810 we know security vulnerabilities and bugs will exist with exist in operating systems with existing applications. 02:17.810 --> 02:21.960 It will exist in hardware exist in the tools that we use. 02:22.210 --> 02:26.040 So to mitigate this we need to distribute trust. 02:26.050 --> 02:29.090 We need to reduce attack surfaces. 02:29.160 --> 02:35.400 We do create isolation and compartmentalization and build layers of defenses. 02:35.530 --> 02:38.430 This will protect us from the book written code. 02:38.560 --> 02:42.600 All of these mitigations we go through in detail throughout the course. 02:42.930 --> 02:47.320 Let's talk about back doors now in relation to your trust. 02:47.320 --> 02:50.260 The back door is a loaded term. 02:50.260 --> 02:56.640 It's a general loaded term let's just consider it as a term to mean a weakening of a system. 02:56.920 --> 03:00.300 And here you can see examples of back doors. 03:00.460 --> 03:05.620 But you should probably take these with a pinch of salt because some of them actually don't think are 03:05.620 --> 03:07.850 potentially accurate. 03:07.900 --> 03:16.560 You know there's a whole list of them from the canoe project potential back doors and phones and applications 03:17.090 --> 03:21.500 and operating systems etc. etc.. 03:21.590 --> 03:29.010 Rooters but those can be introduced by accident through human error or on purpose by an adversary. 03:29.190 --> 03:37.050 If something is closed source the only way to find back doors is through a process called reverse engineering. 03:37.050 --> 03:46.500 This is not feasible for most people and is also on lightly to find anything well-hidden with closed 03:46.500 --> 03:47.370 source. 03:47.580 --> 03:51.390 You have to trust the developer which is not ideal. 03:51.600 --> 03:59.480 Open source systems have less risk of backdoor as potentially as the code is open to public scrutiny. 03:59.760 --> 04:07.290 But using open source does not automatically prevent back doors which a lot people think and it certainly 04:07.290 --> 04:13.380 doesn't prevent security vulnerabilities that can be used as back doors with open source. 04:13.380 --> 04:20.730 If we download a news pre-compiled binary is there is nothing to confirm that the clean source code 04:21.000 --> 04:29.220 published was used to build the binary you are using those you compile distribute and host the boundaries 04:29.520 --> 04:30.900 cannot back doors. 04:31.080 --> 04:31.830 The binary is. 04:31.830 --> 04:35.860 And the signatures could be replaced by an adversary. 04:36.030 --> 04:42.110 Even if you create your own binary from source code there is no guarantee that there is no back door. 04:42.240 --> 04:49.140 You would have to have personally reviewed the source code before compiling it which is often completely 04:49.140 --> 04:56.340 infeasible or you would have to validate the signature of clean source code before compiling it. 04:56.400 --> 04:58.440 How do we know the source code is clean. 04:58.740 --> 05:01.000 Well it's a hard problem. 05:01.050 --> 05:08.700 The compilers used by developers could be backdoor to create back doors in the application they compile 05:08.940 --> 05:16.110 without the developers knowing this happened to a pirated version of X code which resulted in malware 05:16.380 --> 05:18.810 infecting apps on the Apple store. 05:18.930 --> 05:25.950 Developers of the apps were oblivious that they were adding malware when compiling using this pirated 05:25.950 --> 05:27.290 version of X card. 05:27.420 --> 05:34.920 You'll get back doors forced onto you by legislation from nation states which is an imminent problem 05:35.300 --> 05:40.000 and that those can be very very sneaky too and difficult to spot. 05:40.110 --> 05:47.550 Just the slightest deliberate or accidental changing code can create a vulnerability and it can create 05:47.550 --> 05:48.990 a backdoor. 05:49.030 --> 05:56.220 An example here of juniper routers being back door and I'll read a summary here by Mark Green who was 05:56.220 --> 06:03.420 part of an investigation into this particularly sneaky back door for the past several years. 06:03.420 --> 06:10.260 It appears that Juniper net screen devices having corporally potentially backdoor random number generator 06:10.590 --> 06:14.520 based on the NSA is jus ECD RBC algorithm. 06:14.670 --> 06:20.380 At some point in 2012 the next screen code was further subverted by some unknown party. 06:20.450 --> 06:25.630 So that same back door could be used to eavesdrop on net screen connections. 06:25.680 --> 06:31.830 While this alteration was not authorized by Juniper it's important to know that the attacker made no 06:31.830 --> 06:35.030 major code changes to the encryption mechanism. 06:35.040 --> 06:37.170 They only change parameters. 06:37.170 --> 06:43.180 This means that the systems were potentially vulnerable to all the parties even beforehand. 06:43.230 --> 06:50.880 Worse the nature of this vulnerability is particularly insidious and generally messed up and very very 06:51.120 --> 06:52.630 subtle backdoor. 06:52.740 --> 07:01.120 Clearly a nation state or an expert hacker group but also interesting that it's based on NSA is jus 07:01.190 --> 07:09.870 E C D R B.G. algorithm which is one reason why people don't necessarily trust the standards put forward 07:09.870 --> 07:16.320 by the NSA in the NYST standards because they believe that they've been deliberately specified in such 07:16.320 --> 07:19.290 a way that some of them are deliberately weak. 07:19.290 --> 07:25.530 Personally I think for anyone who really cares about security privacy and anonymity back doors are a 07:25.530 --> 07:27.030 serious problem. 07:27.030 --> 07:33.390 Any tools you use going forward through legal methods which is extremely worrying or through hacking 07:33.690 --> 07:37.920 will be a target of back doors and weakening. 07:37.920 --> 07:39.820 Everything will be a target. 07:39.900 --> 07:47.640 Operating Systems encryption security services applications and even the hardware and firmware any anonymising 07:47.640 --> 07:54.870 service you can think of will be under attack from hackers Corp and nation states to back door them 07:55.280 --> 07:58.610 and you can't just create a backdoor just for the good guys. 07:58.650 --> 08:01.830 Once you weaken security you weaken it for everybody. 08:01.830 --> 08:04.160 So how do you mitigate the risk from back doors. 08:04.200 --> 08:11.100 Well we have deterministic and reproducible builds that can help to detect back doors. 08:11.200 --> 08:18.420 So reproduceable Bill usual bills are a set of software development practices which create a verifiable 08:18.420 --> 08:25.700 path from human readable source code to binary code used by computers. 08:25.830 --> 08:32.070 That means the source code that a binary is set to be compiled from is genuinely compiled from it with 08:32.070 --> 08:35.210 reproducible builds multiple parties. 08:35.220 --> 08:40.800 We do build independently and ensure they all get exactly the same result. 08:40.920 --> 08:43.420 But this is easier said than done. 08:43.470 --> 08:48.900 The build system needs to be made entirely deterministic and the build environment should either be 08:48.900 --> 08:51.100 recorded or predefined. 08:51.120 --> 08:54.390 You also need to be able to validate the results. 08:54.420 --> 09:00.990 They need to be given a way to recreate a close enough build environment perform the build process and 09:00.990 --> 09:04.570 verify that the output matches the original build. 09:04.740 --> 09:12.440 So real full deterministic and reproducible builds take lots of effort and are hard to set up. 09:12.540 --> 09:19.320 To my knowledge there are no fully deterministically Bill operating systems yet there is good work going 09:19.320 --> 09:25.200 on in the Debian Project which is one of the reasons why I recommend it as an operating system for people 09:25.200 --> 09:28.230 who care about security privacy and anonymity. 09:28.230 --> 09:35.400 If your operating system is backdoor or your precautions fail so it's vital your operating system is 09:35.400 --> 09:36.030 solid. 09:36.030 --> 09:38.850 Debian is taking strides to get there. 09:38.880 --> 09:45.930 If we look here we can also see all of these we discussed later. 09:45.930 --> 09:50.460 We're also making strides towards deterministic and reproducible builds 09:54.600 --> 10:01.320 and if you're interested more in the topic maybe you a developer and this is quite a good read by a 10:01.320 --> 10:09.650 gentleman called Mike Parry on deterministic builds in relation to Tor but it's also a good read. 10:09.850 --> 10:13.480 And here is a video on how to build your own software. 10:13.480 --> 10:14.500 Reproducibly.