[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Transparency into private keys of Debian



Simon Josefsson:

Hans-Christoph Steiner <hans@at.or.at> writes:


Thanks for digging in here, its very important work!  I'd be happy to
contribute where I can.  I'm a DD and a core contributor to F-Droid,
where we wrestle with basically the same issues.  So we've thought a
lot about these kinds of things, but definitely do not have all the
answers.  Since F-Droid started much later than Debian, we were able
to build in some nice protections from the beginning, like requiring
HTTPS.  We've also made the decision to stick with a single
jurisdiction for the singing keys, even though it is not the best one
for our needs.  We'd of course love to move them to the best
jurisdiction but that is actually quite a bit of work, so we have to
stay grounded in reality.

For me the hard part of all this is how to be transparent as possible
without putting a giant target on the heads of the people who control
the keys.  I think it is clear that publishing private key usage
information is safe, like this key signed these things at these times.
Publishing all the details about how the key was generated could help
those who want to attack it more than those who rely on it.  But that
kind of information would be good to share internally to the project
at the very least.


Good aspect -- and indeed this is a trade-off, and thanks for caring
about these issues for f-droid!  It seems that if you would verify
signatures via a transparency log, you would reduce the risk on the
people controlling the keys?  Then you (and they) could feel more
comfortable publishing information how your process work. That would be
valuable to publish (even de-personalized or generalized) as a best
practices approach.  The reason is that anyone stealing the keys from
these persons would ALSO have to upload signatures of whatever they
wanted to use these keys for into the transparency log, which would
provide evidence to what they did, so they may be less likely to follow
through on their plans.
Yes, I agree, and am familiar with this architecture. The hard part is the availability of the transparency log needs to be as good as the signed index's availability, otherwise attackers can just block the transparency log to stop the whole process. The official F-Droid client does a lot of things automatically in order to find a working mirror. And we're expanding on that. I have yet to see a transparency log set up for decentralized, flexible distribution. F-Droid's mirror handling will automatically choose from: 

* f-droid.org
* Any of the official mirrors
* Any mirrors that the user has added locally
* Files hosted on IPFS
* Mirrors on local storage (SD cards, thumb drives, etc)

We're expanding to:
* Mirrors on cloud file storage like Nextcloud, Google Drive, etc.
* Signed JSON on public code distribution platforms and CDNs
(As a side note: I would like to see Debian/apt adopt this approach, at least optionally. The key part is automatic operation and dead simple setup, e.g. for non-technical users.) 


What would be involved is to 1) during signing of artifacts, also sign
and upload into Sigstore/Sigsum, and 2) during verification in the
f-droid app, also verify that the signature has been committed to the
Sigstore/Sigsum logs.  Both projects have clients written in Go which
should work on Android, but the rest of the details are sketchy to me.
I'm happy to continue discuss and help with design if you are
interested, to understand what the limitations of your environments are
and how to resolve them.
I've looked at Sigstore, it looks nice. It seems to be architected for use cases that assume highly reliable and unblocked single domains. That's a showstopper for us. Also, the official client app is 100% JVM code right now (Java+Kotlin), so integrating Go binaries would really be an option of last resort. Its almost a no go for many reasons. 

Hans



/Simon


And publishing the jurisdictions could be enough info to deanonymize
the key holder, e.g. if it is Germany, then there are many DDs there.
If it is Iceland, then govs can easily find who to target.

.hc


Hi
I'm exploring how to defend against an attacker who can create valid
signatures for cryptographic private keys (e.g., PGP) that users need to
trust when using an operating system such as Debian.  A signature like
that can be used in a targetted attacks against one victim.
For example, apt does not have any protection against this threat
scenario, and often unprotected ftp:// or http:// transports are used,
which are easy to man-in-the-middle.  Even with https:// there is a
large number of mirror sites out there that can replace content you get.
There is a risk that use of a compromised trusted apt PGP key will not
be noticed.  Attackers are also in a good position to deny themselves
out of their actions if they are careful.
Part of my effort is to inventory all trusted private keys that a
distribution needs to manage on their own, or depend on that are managed
by others, and gain some insight how these keys are handled.
Does the Debian project, or any members, publish information on
these
topics?  Has this been discussed before?
Some questions that I think would be useful to answer include:
1) List of relevant private keys, held by the organization, its
members,
    or someone else.  As far as I can tell from Debian, the list includes
    the following PGP trust anchors:
       B8B8 0B5B 623E AB6A D877  5C45 B7C5 D7D6 3509 47F8
       05AB 9034 0C0C 5E79 7F44  A8C8 254C F3B5 AEC0 A8F0
       4D64 FEC1 19C2 0290 67D6  E791 F8D2 585B 8783 D481
       1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
       AC53 0D52 0F2F 3269 F5E9  8313 A484 4904 4AAD 5C5D
       A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793
       80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
       5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA
       6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517
    Compromising any single key on this list leads to trouble.
However I
    don't think this list is complete.  What other keys are there?
    I believe there are keys used to sign some component of the boot
    phase, compare the 'shim-signed' and 'grub-efi-amd64-signed'
    packages.  What private keys held by Debian are involved here?  What
    keys held by others are involved?  What other similar packages
    exists?
2) For each private key, information about its management and
lifecycle.
    Relevant questions include:
  a) How was the key generated?  By whom?  On what hardware?  What
     software?  In what environment?  What legal jurisdiction apply to
     people involved?
  b) How is the key stored and protected during its lifetime?  What
media
     is used?  Who control the physical storage of the key?  How are they
     stored and transported?  What jurisdiction?
  c) Under what policy is the key used?  What should it sign?  Who
     authorize the signing?  What hardware and software is used?  What
     jurisdiction?
  d) For externally held keys, what are the legal terms we use the
keys
     under?  What insight into key transparency questions do we have?
     What of those can we make public?  How do they restrict what we are
     allowed to do?
3) Which less visible private keys are indirectly trusted by users
of
    the distribution?  For example, all DD PGP keys are indirectly
    trusted since they are permitted to make uploads into the archive.
    Host keys used to authorized access to sensitive systems may also be
    relevant.  I'm primarily thinking SSH private keys to a system that
    may have online access to a private key signing oracle.  Indirectly,
    questions about authentication protocols and authorization methods
    are relevant.
To the extent that symmetric shared secrets (rather than asymmetric
public/private keys) are involved, the same question applies.
Other aspects worth exploring?
I understand commercial distributions have different incentives
related
to making this information public.  They have a commercial interest to
defend, and has usually entered various legal arrangements that create
obstacles related to releasing information.  As we've seen with the
WebPKI CA business, that model does not inspire trust and leads to
systematic failures.  More transparent approaches like Certificate
Transparency and LetsEncrypt evolved as a consequence.
I believe that Debian is in a good position to improve things and,
if
there is interest, could lead the way by documenting a better approach,
and describe how to deal with these concerns in a more transparent way
than what we do today.
Thoughts?
/Simon
Reply to: