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.