> From: Antony Vennard [mailto:antony@xxxxxxxxxx] > Sent: Tuesday, January 18, 2022 9:50 PM > Hi All, > > On 17/01/2022 16:02, James Bottomley wrote: > > On Mon, 2022-01-17 at 15:34 +0100, Jason A. Donenfeld wrote: > >> Hi, > >> > >> While it looks like you put a lot of work into this patchset, I think > >> the general idea of adding PGP *to the kernel* is a pretty daunting > >> proposition. The general consensus in the crypto engineering world is > >> that PGP ought to be on its way out. We definitely don't want to > >> perpetuate this project-on-life-support into the permanence of kernel > >> code. Some quick Google searches will reveal a litany of blog posts > >> to the tune of, "why oh why are people still using this?" Here's one > >> from 2019: > >> https://latacora.micro.blog/2019/07/16/the-pgp-problem.html . I > >> think these are arguments to take seriously. And even if you disagree > >> with some parts, you may want to consider whether the remaining parts > >> warrant a bit of pause before adding this to the kernel and > >> perpetuating PGP's design further. > > So while I understand why this is being proposed and clearly effort has > gone into it, I also think it is not the right approach. It seems this > proposal is to include a full PGP packet parser and verification logic > in the kernel as an equivalent to allow PGP signatures to be submitted > via FS_IOC_ENABLE_VERITY: > > "FS_IOC_ENABLE_VERITY accepts a pointer to a PKCS#7 formatted detached > signature in DER format of the file’s fs-verity digest." > > I may be misinterpreting, but as I understand it logic for X.509/PKCS > validation already exists in-kernel because of UEFI and module signing, > so this signature would be verified up to trusted roots. The proposal is > to duplicate all of this logic but in terms of PGP-formatted keys. > > I believe this is unnecessary. Since it seems to require both a > signature and verification up to a root, and distributions like Fedora > already deal with x509 module signing keys for their kernel modules, I > can't see the merit in including the full PGP system too. The One of the problems, but I need to verify that, is that the key used for signing kernel modules might be available only when the kernel package is built. The GPG key should be available for every RPM. If the GPG key is the only available, then probably the least-effort option would be to load the GPG key as it is. Or you have to create a dummy, unsigned X509 certificate with the public key extracted from the GPG key. The other option I mentioned in this discussion was to introduce a simple format to upload the key to the kernel, which still does not eliminate the risks due to parsing data. In addition to that, there is the problem of maintaining the correct key IDs. If you create a dummy X509 certificate, this means calculating a new ID and using them in the signatures. The last problem of trying to reuse the GPG key and convert it to a dummy X509 certificate is that the keyring restriction will not work. IMA and EVM keyrings requires that the key being added is signed with one of the keys in the built-in or secondary keyring. With the dummy X509 certificate, using those keyrings would not be possible. Maybe you could include the signature in the X509 certificate, but you probably would not be able to calculate the digest for verifying the signature in the same way PGP does. > least-effort approach, I would suggest, is to include an x509 > representation of the signature in the RPM and use the existing API to > push that up into the kernel, with the trust anchor the same as is used > for module signing keys, or whatever distributions prefer (they, after > all, control the kernel trust anchors). It could be even easier. IMA has already a very simple signature format. However, the main problem is the management of the keys required to verify the signatures. After several iterations, trying to remove anything that was not essential from the patch set, I came to the conclusion that having the logic for both the keys and the signatures was the best compromise. True, it means more maintenance effort for the kernel, but this ensures the best interoperability with the current ecosystem. I think the code is not particularly complicated that would be impractical to review. > I understand this requires some effort, but so too does maintaining a > fully fledged PGP packet parser as privileged code for all time, and I > think maintaining this in userspace is a) easier and b) less costly than > doing it in kernel. As an added bonus, a PGP-parsing library in a > memory-safe language could be used in userspace. It just needs to parse the key, user ID and the signature packet and subpackets. Consider also that after parsing, nothing about PGP remains in the kernel. The asymmetric key type maintains just the public key, the key ID and the signature of the key (optionally). > A slightly more drastic step would be to wholesale move to PKCS > signatures for packaging. Linux distributions could be their own trusted > roots for this purpose if they so desired, and since they control > certificate bundles anyway they've no need to add them to the browser > list if that is a concern, and can issue certs without SSL Client/SSL > Server types and OIDs. > > > The reason is simple though: for all the detractors and whining, no- > > one's actually been able to come up with a more usable replacement. > > Very few people who complain about GPG actually submit patches to fix > > it. A few come up with their own infrastructure which tends to have > > even more problems. > > Probably replacing with PKCS is a non-starter, but it is at least > possible and it is highly likely distros package one or more tools > capable of validating such signatures in their base installs. > > There are multiple problems with PGP that receive complaints. They are: > > 1) No forward secrecy in messaging-based crypto. > 2) The data format. > 3) Outdated cryptography still supported. > 4) UX. We are using PGP just for a very specific purpose, verifying signatures. Outdated cryptography could be disabled, if we wish. > Of these, all four could be levelled against PKCS standards and related > tools too (except TLS protocols for the first point), and only 2 and 3 > are relevant here since we are concerned with signature validation only. > > I'm not "against" PGP per se, but I'm not convinced by the idea of > adding PGP support just for fs-verity. > > >> If you're looking for a simple signature mechanism to replace the use > >> of X.509 and all of that infrastructure, may I suggest just coming up > >> with something simple using ed25519, > > > > Please, no, use universally supported crypto that we can use TPM > > hardware for, which for EC currently means P-256. It may be possible > > to get the TCG and the other security bodies to add Edwards signatures > > but the rate of progression of quantum means that Grover's Algorithm > > will likely get there first and we'll need P-521 or X448. > > I agree: whatever is chosen should in my view have decent support for > hardware-backed keys, because I strongly hope that is what distribution > key storage looks like. If not I might need to move to Gentoo. > > The current RPM signing keys for Fedora are RSA-4096, which in my > opinion does not actually meet the bar for "good hardware support for > algorithm". RSA-2048 tokens are common, but 4096 much less so. > > Unfortunately for this reason signify/minisign is not ideal as tools: so > far as I can see it has no support for hardware-backed keys. That's not > to say they couldn't, although they both use ed25519. > > I am not sure if we'll end up in the situation where Grover's algorithm > is efficient but Shor is not, but this is all guesswork until we get > closer to a quantum computer with enough logical Qubits. But your > substantive point I think is valid: hardware vendors are disappointingly > slow at adopting edwards curves. > > >> similar to signify or minisign? Very minimal code in the kernel, in > >> userspace, and very few moving parts to break. > > > > Heh, this is the classic cryptographers dilemma: go for something > > pejorative which can be minimal but which has only a relatively small > > set of possible use cases and no future proofing or go for something > > extensible which ends up more complex and others then criticize as > > being a "swiss army knife". > > I think this is the wrong framing for the problem. We already have one > extensible system that is complicated in the kernel. This patch proposes > to add a second one achieving the same purpose instead of a userspace > solution to take advantage of the existing code, which I think would be > preferable and safer. Sorry, I think that forcing all Linux distributions to do it seems unrealistic. Parsing data in the PGP format seems to be the only barrier. Once we are confident that we parse this small number of packets correctly, the rest is just reusing the mechanisms already in place. And we make it easier for people to adopt security features. Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
