> > 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. I should have checked before sending the previous email, there is this client: https://git.glasklar.is/sigsum/core/sigsum-py I suppose for apt python is more relevant, and if the sigsum proof is included alongside apt metadata, it would allow offline verification inside apt. If apt doesn't support this natively, the proof would have to be distributed through some other channel, but that is relatively easy to do as a Proof-of-Concept (i.e., how apt-sigstore + debdistcanary already works via gitlab) but scaling it to decentralized etc remains to be resolved, if relevant. /Simon > > /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