A question we need to ask is how much can we trust the operating systems and the applications that we

use.

Well we know with 100 percent certainty that all of them contain security vulnerabilities and Bogues

one approach to avoid bugs is to create unknown complex systems.

But this is feasible.

In fact systems are getting more complex which is one of the reasons security is struggling to keep

up.

Complexity is the nemesis of security.

Another approach to try and help protect us from these known vulnerabilities and Bogues is to use what

is called formal methods in software engineering.

Software is fundamentally a mathematical system.

Therefore you can prove the correctness of a system through testing and proving properties of that
system.

This way you can provide complete evidence of correctness meaning no matter what inputs the system
receives

it will always compute the right values.

This isn't a new concept.

This formal process was really performed by human mathematicians which was feasible on programs
with

15 lines of code or so in the past.

But with today's systems containing millions of lines it's impossible for a human to do.

But what has happened recently is that both algorithms to proof and the computer power have
improved

enough of their computers can do the proofing for us.

Unfortunately Currently only the most critical software goes through formal methods like air
transportation

or process control systems.

Formal process is still too time consuming and cost prohibitive for most systems so most software testing

today doesn't provide complete evidence of correctness proven mathematically.

So we have to accept the risk of security vulnerabilities and Bogues and mitigate accordingly because

we know security vulnerabilities and bugs will exist with exist in operating systems with existing
applications.

It will exist in hardware exist in the tools that we use.

So to mitigate this we need to distribute trust.

We need to reduce attack surfaces.

We do create isolation and compartmentalization and build layers of defenses.

This will protect us from the book written code.

All of these mitigations we go through in detail throughout the course.

Let's talk about back doors now in relation to your trust.

The back door is a loaded term.

It's a general loaded term let's just consider it as a term to mean a weakening of a system.

And here you can see examples of back doors.

But you should probably take these with a pinch of salt because some of them actually don't think are
potentially accurate.

You know there's a whole list of them from the canoe project potential back doors and phones and
applications

and operating systems etc. etc..

Rooters but those can be introduced by accident through human error or on purpose by an adversary.

If something is closed source the only way to find back doors is through a process called reverse
engineering.

This is not feasible for most people and is also on lightly to find anything well-hidden with closed

source.

You have to trust the developer which is not ideal.

Open source systems have less risk of backdoor as potentially as the code is open to public scrutiny.

But using open source does not automatically prevent back doors which a lot people think and it
certainly

doesn't prevent security vulnerabilities that can be used as back doors with open source.

If we download a news pre-compiled binary is there is nothing to confirm that the clean source code
published was used to build the binary you are using those you compile distribute and host the
boundaries

cannot back doors.

The binary is.

And the signatures could be replaced by an adversary.

Even if you create your own binary from source code there is no guarantee that there is no back door.

You would have to have personally reviewed the source code before compiling it which is often
completely

infeasible or you would have to validate the signature of clean source code before compiling it.

How do we know the source code is clean.

Well it's a hard problem.

The compilers used by developers could be backdoor to create back doors in the application they
compile

without the developers knowing this happened to a pirated version of X code which resulted in malware

infecting apps on the Apple store.

Developers of the apps were oblivious that they were adding malware when compiling using this pirated

version of X card.

You'll get back doors forced onto you by legislation from nation states which is an imminent problem

and that those can be very very sneaky too and difficult to spot.

Just the slightest deliberate or accidental changing code can create a vulnerability and it can create

a backdoor.

An example here of juniper routers being back door and I'll read a summary here by Mark Green who
was

part of an investigation into this particularly sneaky back door for the past several years.

It appears that Juniper net screen devices having corporally potentially backdoor random number
generator

based on the NSA is jus ECD RBC algorithm.

At some point in 2012 the next screen code was further subverted by some unknown party.

So that same back door could be used to eavesdrop on net screen connections.
While this alteration was not authorized by Juniper it's important to know that the attacker made no

major code changes to the encryption mechanism.

They only change parameters.

This means that the systems were potentially vulnerable to all the parties even beforehand.

Worse the nature of this vulnerability is particularly insidious and generally messed up and very very

subtle backdoor.

Clearly a nation state or an expert hacker group but also interesting that it's based on NSA is jus

E C D R B.G. algorithm which is one reason why people don't necessarily trust the standards put forward

by the NSA in the NYST standards because they believe that they've been deliberately specified in such

a way that some of them are deliberately weak.

Personally I think for anyone who really cares about security privacy and anonymity back doors are a

serious problem.
Any tools you use going forward through legal methods which is extremely worrying or through hacking

will be a target of back doors and weakening.

Everything will be a target.

Operating Systems encryption security services applications and even the hardware and firmware any
anonymising

service you can think of will be under attack from hackers Corp and nation states to back door them

and you can't just create a backdoor just for the good guys.

Once you weaken security you weaken it for everybody.

So how do you mitigate the risk from back doors.

Well we have deterministic and reproducible builds that can help to detect back doors.

So reproduceable Bill usual bills are a set of software development practices which create a verifiable

path from human readable source code to binary code used by computers.

That means the source code that a binary is set to be compiled from is genuinely compiled from it with

reproducible builds multiple parties.

We do build independently and ensure they all get exactly the same result.

But this is easier said than done.

The build system needs to be made entirely deterministic and the build environment should either be

recorded or predefined.

You also need to be able to validate the results.

They need to be given a way to recreate a close enough build environment perform the build process
and

verify that the output matches the original build.

So real full deterministic and reproducible builds take lots of effort and are hard to set up.

To my knowledge there are no fully deterministically Bill operating systems yet there is good work going

on in the Debian Project which is one of the reasons why I recommend it as an operating system for
people

who care about security privacy and anonymity.

If your operating system is backdoor or your precautions fail so it's vital your operating system is
solid.

Debian is taking strides to get there.

If we look here we can also see all of these we discussed later.

We're also making strides towards deterministic and reproducible builds

and if you're interested more in the topic maybe you a developer and this is quite a good read by a

gentleman called Mike Parry on deterministic builds in relation to Tor but it's also a good read.

And here is a video on how to build your own software.

Reproducibly.