1 00:00:00,470 --> 00:00:06,570 A question we need to ask is how much can we trust the operating systems and the applications that we 2 00:00:06,570 --> 00:00:07,370 use. 3 00:00:07,560 --> 00:00:14,820 Well we know with 100 percent certainty that all of them contain security vulnerabilities and Bogues 4 00:00:16,060 --> 00:00:21,290 one approach to avoid bugs is to create unknown complex systems. 5 00:00:21,340 --> 00:00:23,510 But this is feasible. 6 00:00:23,560 --> 00:00:29,790 In fact systems are getting more complex which is one of the reasons security is struggling to keep 7 00:00:29,790 --> 00:00:30,020 up. 8 00:00:30,040 --> 00:00:33,760 Complexity is the nemesis of security. 9 00:00:33,760 --> 00:00:40,660 Another approach to try and help protect us from these known vulnerabilities and Bogues is to use what 10 00:00:40,660 --> 00:00:44,110 is called formal methods in software engineering. 11 00:00:44,350 --> 00:00:47,680 Software is fundamentally a mathematical system. 12 00:00:47,920 --> 00:00:55,640 Therefore you can prove the correctness of a system through testing and proving properties of that system. 13 00:00:55,660 --> 00:01:03,460 This way you can provide complete evidence of correctness meaning no matter what inputs the system receives 14 00:01:03,520 --> 00:01:06,580 it will always compute the right values. 15 00:01:06,580 --> 00:01:07,890 This isn't a new concept. 16 00:01:07,900 --> 00:01:15,850 This formal process was really performed by human mathematicians which was feasible on programs with 17 00:01:15,850 --> 00:01:18,950 15 lines of code or so in the past. 18 00:01:19,330 --> 00:01:26,700 But with today's systems containing millions of lines it's impossible for a human to do. 19 00:01:26,890 --> 00:01:34,690 But what has happened recently is that both algorithms to proof and the computer power have improved 20 00:01:34,690 --> 00:01:37,990 enough of their computers can do the proofing for us. 21 00:01:38,320 --> 00:01:46,700 Unfortunately Currently only the most critical software goes through formal methods like air transportation 22 00:01:46,700 --> 00:01:48,860 or process control systems. 23 00:01:49,240 --> 00:01:56,350 Formal process is still too time consuming and cost prohibitive for most systems so most software testing 24 00:01:56,350 --> 00:02:01,900 today doesn't provide complete evidence of correctness proven mathematically. 25 00:02:01,930 --> 00:02:10,150 So we have to accept the risk of security vulnerabilities and Bogues and mitigate accordingly because 26 00:02:10,150 --> 00:02:17,810 we know security vulnerabilities and bugs will exist with exist in operating systems with existing applications. 27 00:02:17,810 --> 00:02:21,960 It will exist in hardware exist in the tools that we use. 28 00:02:22,210 --> 00:02:26,040 So to mitigate this we need to distribute trust. 29 00:02:26,050 --> 00:02:29,090 We need to reduce attack surfaces. 30 00:02:29,160 --> 00:02:35,400 We do create isolation and compartmentalization and build layers of defenses. 31 00:02:35,530 --> 00:02:38,430 This will protect us from the book written code. 32 00:02:38,560 --> 00:02:42,600 All of these mitigations we go through in detail throughout the course. 33 00:02:42,930 --> 00:02:47,320 Let's talk about back doors now in relation to your trust. 34 00:02:47,320 --> 00:02:50,260 The back door is a loaded term. 35 00:02:50,260 --> 00:02:56,640 It's a general loaded term let's just consider it as a term to mean a weakening of a system. 36 00:02:56,920 --> 00:03:00,300 And here you can see examples of back doors. 37 00:03:00,460 --> 00:03:05,620 But you should probably take these with a pinch of salt because some of them actually don't think are 38 00:03:05,620 --> 00:03:07,850 potentially accurate. 39 00:03:07,900 --> 00:03:16,560 You know there's a whole list of them from the canoe project potential back doors and phones and applications 40 00:03:17,090 --> 00:03:21,500 and operating systems etc. etc.. 41 00:03:21,590 --> 00:03:29,010 Rooters but those can be introduced by accident through human error or on purpose by an adversary. 42 00:03:29,190 --> 00:03:37,050 If something is closed source the only way to find back doors is through a process called reverse engineering. 43 00:03:37,050 --> 00:03:46,500 This is not feasible for most people and is also on lightly to find anything well-hidden with closed 44 00:03:46,500 --> 00:03:47,370 source. 45 00:03:47,580 --> 00:03:51,390 You have to trust the developer which is not ideal. 46 00:03:51,600 --> 00:03:59,480 Open source systems have less risk of backdoor as potentially as the code is open to public scrutiny. 47 00:03:59,760 --> 00:04:07,290 But using open source does not automatically prevent back doors which a lot people think and it certainly 48 00:04:07,290 --> 00:04:13,380 doesn't prevent security vulnerabilities that can be used as back doors with open source. 49 00:04:13,380 --> 00:04:20,730 If we download a news pre-compiled binary is there is nothing to confirm that the clean source code 50 00:04:21,000 --> 00:04:29,220 published was used to build the binary you are using those you compile distribute and host the boundaries 51 00:04:29,520 --> 00:04:30,900 cannot back doors. 52 00:04:31,080 --> 00:04:31,830 The binary is. 53 00:04:31,830 --> 00:04:35,860 And the signatures could be replaced by an adversary. 54 00:04:36,030 --> 00:04:42,110 Even if you create your own binary from source code there is no guarantee that there is no back door. 55 00:04:42,240 --> 00:04:49,140 You would have to have personally reviewed the source code before compiling it which is often completely 56 00:04:49,140 --> 00:04:56,340 infeasible or you would have to validate the signature of clean source code before compiling it. 57 00:04:56,400 --> 00:04:58,440 How do we know the source code is clean. 58 00:04:58,740 --> 00:05:01,000 Well it's a hard problem. 59 00:05:01,050 --> 00:05:08,700 The compilers used by developers could be backdoor to create back doors in the application they compile 60 00:05:08,940 --> 00:05:16,110 without the developers knowing this happened to a pirated version of X code which resulted in malware 61 00:05:16,380 --> 00:05:18,810 infecting apps on the Apple store. 62 00:05:18,930 --> 00:05:25,950 Developers of the apps were oblivious that they were adding malware when compiling using this pirated 63 00:05:25,950 --> 00:05:27,290 version of X card. 64 00:05:27,420 --> 00:05:34,920 You'll get back doors forced onto you by legislation from nation states which is an imminent problem 65 00:05:35,300 --> 00:05:40,000 and that those can be very very sneaky too and difficult to spot. 66 00:05:40,110 --> 00:05:47,550 Just the slightest deliberate or accidental changing code can create a vulnerability and it can create 67 00:05:47,550 --> 00:05:48,990 a backdoor. 68 00:05:49,030 --> 00:05:56,220 An example here of juniper routers being back door and I'll read a summary here by Mark Green who was 69 00:05:56,220 --> 00:06:03,420 part of an investigation into this particularly sneaky back door for the past several years. 70 00:06:03,420 --> 00:06:10,260 It appears that Juniper net screen devices having corporally potentially backdoor random number generator 71 00:06:10,590 --> 00:06:14,520 based on the NSA is jus ECD RBC algorithm. 72 00:06:14,670 --> 00:06:20,380 At some point in 2012 the next screen code was further subverted by some unknown party. 73 00:06:20,450 --> 00:06:25,630 So that same back door could be used to eavesdrop on net screen connections. 74 00:06:25,680 --> 00:06:31,830 While this alteration was not authorized by Juniper it's important to know that the attacker made no 75 00:06:31,830 --> 00:06:35,030 major code changes to the encryption mechanism. 76 00:06:35,040 --> 00:06:37,170 They only change parameters. 77 00:06:37,170 --> 00:06:43,180 This means that the systems were potentially vulnerable to all the parties even beforehand. 78 00:06:43,230 --> 00:06:50,880 Worse the nature of this vulnerability is particularly insidious and generally messed up and very very 79 00:06:51,120 --> 00:06:52,630 subtle backdoor. 80 00:06:52,740 --> 00:07:01,120 Clearly a nation state or an expert hacker group but also interesting that it's based on NSA is jus 81 00:07:01,190 --> 00:07:09,870 E C D R B.G. algorithm which is one reason why people don't necessarily trust the standards put forward 82 00:07:09,870 --> 00:07:16,320 by the NSA in the NYST standards because they believe that they've been deliberately specified in such 83 00:07:16,320 --> 00:07:19,290 a way that some of them are deliberately weak. 84 00:07:19,290 --> 00:07:25,530 Personally I think for anyone who really cares about security privacy and anonymity back doors are a 85 00:07:25,530 --> 00:07:27,030 serious problem. 86 00:07:27,030 --> 00:07:33,390 Any tools you use going forward through legal methods which is extremely worrying or through hacking 87 00:07:33,690 --> 00:07:37,920 will be a target of back doors and weakening. 88 00:07:37,920 --> 00:07:39,820 Everything will be a target. 89 00:07:39,900 --> 00:07:47,640 Operating Systems encryption security services applications and even the hardware and firmware any anonymising 90 00:07:47,640 --> 00:07:54,870 service you can think of will be under attack from hackers Corp and nation states to back door them 91 00:07:55,280 --> 00:07:58,610 and you can't just create a backdoor just for the good guys. 92 00:07:58,650 --> 00:08:01,830 Once you weaken security you weaken it for everybody. 93 00:08:01,830 --> 00:08:04,160 So how do you mitigate the risk from back doors. 94 00:08:04,200 --> 00:08:11,100 Well we have deterministic and reproducible builds that can help to detect back doors. 95 00:08:11,200 --> 00:08:18,420 So reproduceable Bill usual bills are a set of software development practices which create a verifiable 96 00:08:18,420 --> 00:08:25,700 path from human readable source code to binary code used by computers. 97 00:08:25,830 --> 00:08:32,070 That means the source code that a binary is set to be compiled from is genuinely compiled from it with 98 00:08:32,070 --> 00:08:35,210 reproducible builds multiple parties. 99 00:08:35,220 --> 00:08:40,800 We do build independently and ensure they all get exactly the same result. 100 00:08:40,920 --> 00:08:43,420 But this is easier said than done. 101 00:08:43,470 --> 00:08:48,900 The build system needs to be made entirely deterministic and the build environment should either be 102 00:08:48,900 --> 00:08:51,100 recorded or predefined. 103 00:08:51,120 --> 00:08:54,390 You also need to be able to validate the results. 104 00:08:54,420 --> 00:09:00,990 They need to be given a way to recreate a close enough build environment perform the build process and 105 00:09:00,990 --> 00:09:04,570 verify that the output matches the original build. 106 00:09:04,740 --> 00:09:12,440 So real full deterministic and reproducible builds take lots of effort and are hard to set up. 107 00:09:12,540 --> 00:09:19,320 To my knowledge there are no fully deterministically Bill operating systems yet there is good work going 108 00:09:19,320 --> 00:09:25,200 on in the Debian Project which is one of the reasons why I recommend it as an operating system for people 109 00:09:25,200 --> 00:09:28,230 who care about security privacy and anonymity. 110 00:09:28,230 --> 00:09:35,400 If your operating system is backdoor or your precautions fail so it's vital your operating system is 111 00:09:35,400 --> 00:09:36,030 solid. 112 00:09:36,030 --> 00:09:38,850 Debian is taking strides to get there. 113 00:09:38,880 --> 00:09:45,930 If we look here we can also see all of these we discussed later. 114 00:09:45,930 --> 00:09:50,460 We're also making strides towards deterministic and reproducible builds 115 00:09:54,600 --> 00: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 116 00:10:01,320 --> 00:10:09,650 gentleman called Mike Parry on deterministic builds in relation to Tor but it's also a good read. 117 00:10:09,850 --> 00:10:13,480 And here is a video on how to build your own software. 118 00:10:13,480 --> 00:10:14,500 Reproducibly.