Software transparency: package security beyond signatures and reproducible builds

This will be an academic talk
as announced.

I will try to bring some of my research
I did during my PhD into the real world.

We are going to talk about the security
of software distribution and

I'm going to propose a security feature
that adds on top of

the signatures we have up to today

and also the reproducible builds that
we already have to very large degree.

I am going to highlight a few points where
I think infrastructure changes are required

to accommodate this system and I would
also appreciate any feedback

you might have.

I'm going to ??? a few motivation of
what should we care about.

In the security of software distribution

we already do have
cryptographic signatures

I've just put up a few examples of
recent attacks that involved

the distribution of software where
people who presumably thought

they knew what they were doing had
grave problems with software distribution.

For example, the juniper backdoors,
pretty famous.

Juniper discovered two backdoors
in the code and

nobody really knew where they were
coming from.

Another example would be
Chrome extension developers

who got their credentials fished and
subsequently their extensions backdoored

or another example, a signed update to
a banking software actually included

a malware and infected several banks.

I hope this is motivation for us to
consider this kinds of text

to be possible and to prepare ourselves.

I have two main goals in the system
I am going to propose.

The first is to relax trust in the archive.

In particular, what I want to achieve is
a level of security even if

the archive is compromised and
the specific thing I am going to do is

to detect targeted backdoors.

That means backdoors that are distributed
only to a subset of the population and

what we can achieve is to force
the attacker to deliver the malware

to everybody, thereby greatly decreasing
their degree of stealth and increasing

their danger of detection.

This would work to our advantage.

The second goal is the forensic auditability

which overlaps to a surprising degree
with the first one in technical terms,

in terms of implementation.

So, what I want to ensure is that we have

inspectable source code for every binary.

We do have of course the source code
available from our packages, but

only for the most recent version,
everything else is a best effort

by the code archiving services.

The mapping between those and binary
can be verified once we have

reproducible builds to a large extent.

I want to make sure that we can identify
the maintainer responsible for distribution

of a particular package and the system
is also interested in providing

attribution of where something went from,

so that we are not in a situation where we
notice something went wrong but

we don't really know where we have to look
in order to find the problems

but that we really have specific and
secured indication of

where a compromised problem
was coming from.

Let's quickly recap how our software
distribution works.

We have the maintainers who upload
their code to the archive.

The archive has access to a signing key
which signs the releases.

Actually, metadata covering all the actual
binary packages.

These are distributed over
the mirror network

from where the app clients will download
the package metadata.

That means the hash sums for the packages,
their dependencies and so on

as well as the actual packages themselves.

This central architecture has an important
advantage,

mainly the mirror network need not
to be trusted, right?

We have the signature that covers all
the contents of binary and source packages

and the metadata, so the mirror network
need not to be trusted.

On the other hand, it makes the archive and
the signing key a very interesting target

for attackers because this central point
controls all the signing operations.

So this is a place where we need to be
particularly careful and perhaps

maybe even do better than
cryptographic signatures.

This is where the main focus of this talk
will be, although I will also consider

the uploaders to some extent.

We want to achieve two things:

resistance against key compromise and
targeted backdoors and

to get some better support for auditing
in case things go wrong.

The approach that we choose to do this is

we want to make sure that everybody runs
exactly the same software

or at least the parts of it these choose
to install.

If we think about that for a moment,
this gives us a number of advantages.

For example, all the analysis that's done
on a piece of software immediately

carries over to all other users of
the software, right?

Because if we haven't made sure that
everybody installs the same software,

they might not have exactly
the same version and perhaps

some backdoored version.

This also ensures that we cannot suffer
targeted backdoors by increasing

the detection risk of attackers

and we also want to have a cryptographic
proof of where something went wrong.

Now, to look at some pictures,
I will present the data structure that

we use in order to achieve these goals.

The data structure is hash tree,
a Merkle tree which is

a data structure that operates over a list.

So we have a list of these squares here
which represent the list items.

In our case, this is going to be
the files containing a package metedata

that just dependencies, a hash sum of
packages

and also the source packages themselves
are going to be elements in this list.

The tree works as follows.

It uses a cryptographic has function

which is a collision resistant compressing
function

and the labels of the inner nodes
of the tree are computed as

the hashes of the children. Ok?

Once we have computed the root hash,
the root label,

we have fixed all the elements and
none of the elements can be changed

without changing the root hash.

We can exploit this in order to
efficiently prove

the two following properties for ???

First of all, we can efficiently prove
the inclusion of a given element

in the list.

If we know the tree root ???,
this works as follows:

let's make a quick example, we see
the third list item is marked with an X

and if I know the tree root, then
the server operating the tree structure

will only need to give me the three grey
marked labels,

the three marked node values and then
I can recompute the root hash and

be convinced that this element actually
was contained in the list.

The second property is that we can also
efficiently verify the append-only operation

of the list.

So we can have a log server operating
this kind of structure and

the log server need not to be trusted,

it's not going to be trusted third party
but rather, its operation can be

verified from the outside.

So, what does this design look like?

The theoretical foundation is called
a transparency overlay and

in our system it looks like this:

We have the archive as per usual,

we have a log server and the archive will
submit package metadata, the release file,

the packages file containing dependencies
and so on and the source code

into this log server.

The app client will be augmented with
an auditor component and

this auditor component is responsible for
verifying the correct log operation

as well as the inclusion of the downloaded
release into the log.