tis 2024-02-06 klockan 16:50 +0100 skrev Hans-Christoph Steiner: > > > 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 I believe sigsum allows for offline verification of the inclusion proof. Just include the transparency checksum proof with the app or meta-data around the app. Not sure about Sigstore. > (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.) +1 > > 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. Agreed -- having a C, perl or python client for Sigstore or Sigsum would be nice. I'll bring this up with them. /Simon > > 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 > > > > > >
Attachment:
signature.asc
Description: This is a digitally signed message part