Stephan Verbücheln <verbuecheln@posteo.de> writes: > II. Typical Debian case > > 1. Debian developer signs source tarballs and upload them > 2. The signature only has to be secure until the code lands in the FTP > 3. Debian builds the binary packages > 4. Debian creates Release files with hashes of the packages > 5. The Release file is signed by Debian APT keys > 6. The signature has to be secure until the next Release file > 7. Security updates have a separate Release file with expiration time > > This strategy effectively prevents attackers from injecting outdated > programs with known vulnerabilities into the updates. Even mirrors > cannot do that. TLS for mirrors is not required for integrity and > authenticity. Thanks for summarizing. I'm not concerned with injecting outdated programs -- I'm concerned with injecting malware indirectly signed by the Debian APT keys, and want to explore ways to mitigate against those attacks. Understanding the private key lifecycle is one way to increase confidence in what the cost of those attacks are -- right now all we can say is that the cost of forging signatures for Debian APT keys is likely higher than $0 and is likely lower than, let's say, $100B to pay someone to get the keys or inject code for malicious remote signing. Tightening these bounds, using some rational methodology, gives us knowledge about safety. Using transparency logging of the signatures created by the private keys is another way to allow detection when this occur, which also increase confidence in the overall security, and reduce the risk with the private keys (since they are longer useful for deniable attacks). It may be that publishing more details about the private key lifecycle is not a good idea unless we have measurements to protect ourselves, but at least establishing that fact would be an improvement, and an incentive to invest in these improvements. /Simon
Attachment:
signature.asc
Description: PGP signature