Bill Allombert <ballombe@debian.org> writes: > On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote: >> Bill Allombert <ballombe@debian.org> writes: >> >> > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit : >> >> 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, >> > >> > Is not apt-key a protection ? >> >> No, the current implementation protects against missing and/or invalid >> signatures. Compare how in the WebPKI world some CA issued a valid >> *.google.com certificate, and how that (and other incidents) lead to >> setup of Certificate Transparency, which helps mitigate these issues. > > The difference is that with apt-key, the list of valid public keys is stored on > the user system (in /etc/apt/trusted.gpg.d/), not a list of root certificates, > and that the users are notified when the keys are updated, which is not the > case with CA. Nobody can generate a new signature that will be accepted by > apt-key out of the box. Right, there are differences, but I believe the underlying problem is the same: if someone mis-use private keys I trust, or is able to forge valid signatures somehow (e.g., crypto attack), apt-key wouldn't notice but in the WebPKI world there are mechanisms to mitigate this via Certificate Transparency. It is a subjective choice to care about this attack scenario, and some may regard it as out of scope, but others can believe it is in scope and that improvements are warranted. /Simon
Attachment:
signature.asc
Description: PGP signature