[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    [qubes-devel] RFC: Hardening Qubes binary distribution process
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2015-05-20 15:28:01
Message-ID: 20150520152801.GB25294 () work-mutt
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

We're currently considering how to further protect Qubes binary production and
distribution process. As discussed recently in the Qubes 3.0-rc1 announcement
[1] we have already taken some steps to harden Qubes binary production process,
e.g. by introducing sandboxed builds using DispVMs for templates, and by using a
TorVM to fetch Fedora packages used by our builder to make it difficult to feed
us (people who build Qubes packages) with backdoored Fedora packages by an
hypothetical adversary who might have access to the Fedora signing key.

Still, we're quite concerned about the possibility of an adversary stealing our
binary signing keys. As one can imagine we have limited possibilities to protect
these keys against sophisticated _physical_ attacks without changing our
apartments into bunkers (which is not necessarily something we might be dreaming
of doing...).

An attacker who might have gained access to the Qubes binary signing keys might
be able to inject backdoored packages to _select_ users without others being
able to ever find out such an attack is going on. This would be very sad and
might have very unpleasant consequences to some of the users.

This attack is, of course, not specific to Qubes in any way -- it applies all
the same way to updates or ISO images downloaded from Fedora or any other
distribution.

In order to protect against such targeted attacks, the more paranoid users might
wish to use Tor for downloading of the updates. We're currently considering
whether we should make this a default option (or at least selectable during
installation) in a future Qubes release (3.1)?

Using Tor for downloading of all the updates for Qubes does not protect,
however, against a situation where the adversary (who managed to steal our
binary signing key) decides to inject maliciously backdoored packages to any and
all Qubes users. Again, there is nothing Qubes-specific in this attack scenario,
and any Linux distribution serving binary updates is just as vulnerable. Except
for the fact that the group of people who happen to be Qubes users might
constitute a somehow more interesting target group for such an attack (e.g.
because "normal Linux" users might be relatively easily attacked in a number of
other, perhaps simpler ways).

As already mentioned several times, the proper way to address this problem is to
introduce a multi-signature scheme in which every (binary) update is signed by
at least M out of N trusted keys, spread among N trusted people, residing in
different countries, having different sources of income, etc. Naturally, this
scheme requires binaries to build deterministically from the same sources, so
that each of these N people could 1) verify the sources, 2) build the binary and
see what is the hash, and 3) sign the hash with their key. Unfortunately
deterministic builds for still months or perhaps even years in front of our
times :/

Thus, in the meantime, I thought it might be reasonable to temporarily solve
this problem by not distributing binaries, but rather only source code and have
all the Qubes updates building on the users computers automatically. This would
allow to easily implement the multi-signature scheme immediately, because all
that would be needed was to check if the source code has been signed by at least
M keys from the group of N well known keys.

Yes, this would mean that updates installation would take significantly longer,
sometimes even a few hours, and would increase energy consumption and heat
production. But it will eliminate the need for Qubes binary signing keys. Yes,
an attacker who manages to steal e.g. Marek's source code signing key would be
able to inject some malicious commits, or modify existing ones, but such
backdooring should be significantly easier to detect by others (especially the
N-1 other trusted people) than the binary modifications.

I would like now to discuss the above idea and hear what people think about it.

One more problem: how to distribute the ISO, which would become the weakest link
in this scheme?

Thanks,
joanna.

[1] http://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJVXKgAAAoJEDOT2L8N3GcY4kIQANZpemsTeoWaGQMHcUiV70gX
OcAL8Wp1nmQpHeeUOmufVxVaYnVMiXjEM9bOEno+7EbowvaNuZtBiurnfHCOSSTi
Kmy234iCpC5xgu6qNgz9b6xuvA05xRdhccWlkDVZnhei2rEfKUxfciUEJtowtnnF
HaDf8caE4mTmJ7oBFXJRpMdTGxLtiog5ehpK5nhT/tu5XmSt+WYKxWeV5QWUNlAU
CXIrUAn8Vz56BiXi4VsnKdqAoomfFDqOKsw/+dBLGsm0N/dLiMQZfmyuiZb/tjHe
FboJdQHxn5VZaVxSTkHRCZMXPuJIiPgdbrvx8WKa6onnCXY56Tf1Jb9RGIEtUSQ7
Svk5DWcha3DfXGDKoV2aWeJ5q9v768aE9MtYuGe9lDl4CfFZWVEmmtU39NH4Zvzd
uEGqIfIEE6yZu4mrp2kbOEykY3oArfVVl1nU+uVyjz2vcqgwAQUHdyCOcM/uAlhj
SOIVst8fPdhs37z9XoBxG1W4xUXJDcYHUZAzGqPiOwYG36g6H8qnvJE0686g9lkp
/eLTN+RmrE04JzJ5AjzothvGsEwsWvFIbRaR4yGtTSNxq1JOa7dR8Qe0FvRu1HD1
ZJTBU1NJSI7rMXNwL3oMrdeB5Zt4nhVkNvcy7pjRwxUUtkyebbfNQyWEwhOT1LMH
ijEmMQXWRos9aieh1rqb
=rP+3
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20150520152801.GB25294%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]