On Tue, May 14, 2024 at 1:28 AM Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote: > > On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@xxxxxxxxxxxxxx> wrote: > > I would like to point out to myself I was wrong: it is possible to ask > > the kernel to generate a trusted key inside the kernel locally with > > "keyctl add trusted kmk "new 32" @u" > > Not in a full-time kernel position ATM as I'm working as contract > researcher up until beginning of Oct (took some industry break after > a startup went down of business), so please, politely asking, write > a bit more compact descriptions ;-) I'm trying to find a new position by > the beginning of Oct but right now I'd appreciate a bit more thought out > text descriptions. > > I'm working out a small patch set with James Prestwood to add asymmetric > TPM2 keys based on his old patch set [1] but laid out on top of the > existing baseline. > > I did already the key type shenanigans etc. for it and James P is laying > his pre-existing RSA code and new ECDSA on top of that. So this will This is great. Perhaps we can finally have ECDSA software signature support as well, which I have been trying to get in for some time now [1] > give x.509 compatibility [2]. This patch set will be out soon and likely > part of 6.11 (or almost guaranteed as most of it is done). > > So by plain guess this might be along the lines what you might want? I don't think so. I have seen this patchset, but unless the new version is fundamentally different, it looks to me that the asymmetric TPM keys are the same as trusted keys except they are asymmetric instead of being symmetric. That is, they are still of limited use on stateless systems and are subject to the same restrictions I described in my revised cover description. On top of that I'm not sure they would be widely used as "leaf" keys by applications, maybe more as root/intermediate keys in some kind of key hierarchy. TPMs are slow and I don't see a high-performance web-server, for example, using asymmetric TPM keys for TLS operations. Also, as we learned the hard way operating many TPMs in production, some TPMs are quite unreliable and fail really fast, if you "spam" them with a lot of crypto ops. I understand this is a HW/TPM vendor problem, but in practice we're trying to build systems, where TPM is used to protect/generate other keys, but most of the "leaf" crypto operations are done in software, so we don't make the TPM do too much crypto. Just to clarify - I'm not arguing about the usefulness of TPM asymmetric keys in the kernel. I would really want to see this building block available as well, but I think it just serves a different purpose/use case from what I'm trying to figure out in this RFC thread. > [1] https://lore.kernel.org/all/20200518172704.29608-1-prestwoj@xxxxxxxxx/ > [2] https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/ > > BR, Jarkko [1] https://lore.kernel.org/lkml/20221014100737.94742-2-ignat@xxxxxxxxxxxxxx/T/
