Keys/Signature use in OSTree/Flatpak/Flathub

[Tobias Mueller]

Hi :-)

On Mi, 2016-10-05 at 15:39 +0200, Alexander Larsson wrote:
> On Wed, 2016-10-05 at 11:37 +0200, Tobias Mueller wrote:
> > 
> > On Fri, Sep 30, 2016 at 03:36:35PM +0200, Alexander Larsson wrote:
> > > 
> > > 
> > >  * OSTree doesn't have any protection against "freeze attacks". I.e
> > >    a MITM can cause a client to not get updates forever without
> > > this
> > >    being detectable.
> > Is this attack something worth defending against?
> > Or rather throwing PKI at it..?
> > I guess a client notices that it receives no updates simply by
> > receiving no updates.
> > If a client really expects an update, it can notice that there
> > haven't been updates for,
> > say, more than a month.
> 
> If there is a known security issue (think heartbleed) and everyone
> needs to update their apps to not be vulnerable, then an undetected
> MITM would make you think you're safe due to automatic updates.
Right.

>  Sure,
> if you're very careful and manually follow updates then you *might*
> notice this. However, the goal is to turn on automatic updates and then
> not have to worry (i.e. get told when something fishy is going on).
I see.  That goal can probably be achieved by the server signing a
timestamp. Clients can then issue warnings if the last timestamp is too
old.  FWIW: OpenPGP signatures already carry a timestamp.  So this
might even come for free.


> Yeah, this is clearly a problem. In TUF only "head" of anything is ever
> valid, and it has to be continually re-signed. How does that combine
> with wanting to run an older version of an app?
I have absolutely no clue.
Might be worth asking on their mailinglist.
Would the idea be to make flatpak a "TUF client"?

> OTOH, at what point does a GPG key lose enough trust due to risk of
> exposure increasing with time, and due to the pki technology going
> forward (key size increases, etc). Is using the same key for 10 years
> safe? If not, what is the future-proofing plan.
The trust in a key with GnuPG does not necessarily degrade. Time only
matters when signatures on a key are set to expire.
There is, AFAIK, no model for rolling over a key. Unfortunately.
With OpenPGP, you can revoke a key and set a flag that you're using a
new key instead. GnuPG, however, ignores that flag. The argument is
that if a key is compromised, that you cannot trust flags on the
revocation. While this is true, I think it's unfortunate that you
cannot convince GnuPG to respect that flag if you're really confident
that the revocation is genuine.


> 
> > 
> > > 
> > > Secondly we add more keys and roles. These are described in a
> > > single
> > > signed "root" file assigning to each role the keys that are allowed
> > > for it.
> > So the "root" file is a file kept in OSTree?
> > Is the app author supposed to create and sign that root file?
> > And is the user supposed to somehow get the key when attempting to
> > install an app?
> > And does the user get this file when they first install an app?
> > When I check for updates, do I again download that root file?
> > Can the key to sign the root file with ever be changed?
> > How do I make sure I'm not getting an attackers root file?
> 
> The current OSTree model depends on a pre-setup of the public GPG key
> for the repo, which is installed out-of-bands (probably got it via
> https). In the TUF-like model the entire root file would be locally
> available as part of bootstrapping a remote. 
I understand that you need to tell the OSTree client about an OpenPGP
key before it can do anything meaningful.
Are you saying that in the
proposal you've made, the client would somehow get this root file
before installing an app?  Along with a timestamp?

> It is self-signed, and the update contains a check for a new version,
> which is then updated to if its properly signed.
Hrm. "if it's properly signed" is key here, I guess.

It should probably be signed by the same key which signed the old root
file.  That is a bit messy when the old key is compromised or lost
(which, I suppose, are the major reasons for rolling over the root
key).

Should non-linear updates be supported? Then clients may have various
versions of the root file and you may never be able to delete (or lose)
a compromised key. You might get away with having multiple key sign the
root files, though.



> > 
> > > 
> > > The summary file is an in-file signed version of the current
> > > summary
> > > file.  Its signed by key(s) assigned to the "summary" role. Also,
> > > it
> > > contains a reference (by sha256) to the root file.
> > So the chain goes like this:  root -> timestamp -> summary -> root ?
> > It seems unusual to go in such a circle.
> > What attack is thwarted by referecing back from the summary to the
> > root?
> 
> It's more like
> 
> root1 -> timestamp -> summary -> root2
> 
> I.e. given a local copy of an old, trusted root we can get to a new
> one, which may have e.g. a new commit gpg key. I.e. this is how
> revocation and similar operations happen.
Cool. I guess the regular case is that the root files are supposed to
be the same.
Again, the question of how to verify the new root file seems important.
I think dealing with inconsistencies is not trivial.
For example, the two root files might define disjoint sets of keys for
signing the timestamp.  Is the timestamp still considered to be valid
because it has been authenticated once? Or rather not, because the
newer root file obsoletes that key?
The client should probably be stuck and require an authentic out-of-
band root file, but unless this is made explicit, clients might behave
differently.

But TUF is taking care of all of that, isn't it?


> > > 
> > > If the referenced root file is different from whats currently in
> > > use,
> > > update it and start over. This is how we add and revoke keys.
> > This seems like a scary operation.  I assume the signature on the new
> > root
> > file still has to come from an authenticated key?  Can the signing-
> > key be
> > different?  What's the mechanism to roll over keys if the root key
> > gets lost
> > (instead of compromised)?
> > Having no mechanism is fine, but it'd better be communicated ;-)
> 
> There is no such mechanism (other than out-of-band), but that is no
> different from the current use of a single GPG key for everything in
> ostree.
okay. cool.

> 
> > 
> > > 
> > > Interestingly, you you can go "unverified timestamp -> unverified
> > > summary -> root file" to get an initial version of the root keys,
> > > which
> > > you can then pin for later use. This is a nice way to bootstrap
> > > trust
> > > in a repo via SSL.
> > In the TUF spec <https://github.com/theupdateframework/tuf/blob/5d2c8
> > fdc7658a9f7648c38b0c79c0aa09d234fe2/docs/tuf-spec.txt#L258>
> > the wording is
> > 
> >    The client-side of the framework must ship with trusted root keys
> > for each
> >    configured repository.
> > 
> > Having this root of trust is a significant advantage in building a
> > PKI,
> > because it reduces complexity.
> > The proposed method here seems to be different in that this intial
> > trust
> > has to be bootstrapped not via hardcoded keys but via downloads.
> 
> No, this is just an optional model. The core idea is that the root keys
> are pre-assigned to the remote just like we currently do with ostree.
Ah, the key that that the user has to obtain out-of-band.

> However, in practice such trust has to be bootstrapped *somehow*, and
> all the current models are "store the gpg key on some https server".
> The above use just notes that this could be done no less secure via the
> repo itself, if it is on https.
right.
My point should be that this model does not necessarily enjoy the same
security properties as the TUF model. Simply by not having a carved in
root of trust.  Then again, I haven't really read all of the spec and
the analyses.

> 
> > 
> > Building a PKI and mandating clients how to define "trust" is a bit
> > of a minefield and you will never please everyone.  In fact, if you
> > ever
> > build a working PKI, I'd nominate you for the nobel prize or,
> > depending on
> > your preference, buy you a crate of beer.
> 
> I think this is expressing a similar opinion to Colin, which I take as
> a hint that the practicality of something as complex as this in very
> low. I guess I'll drop this then.
I wouldn't say that!  Reducing the scope, and thus complexity, might
help to imagine better how this would work and to create an
implementation, though.  Being able to reuse the TUF thoughts is a big
plus. Seems like a C implementation is still missing! ;-)
Do you happen to know whether any application is actually using TUF?

Cheers,
  Tobi