On Tue May 14, 2024 at 1:05 PM EEST, Ignat Korchagin wrote: > 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] Yes exactly both. > > > 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. OK, hmm... can you an "apples and oranges" example what would be most trivial use case where these don't cut? > 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. So what about SGX/SNP/TDX? TPM is definitely not made for workloads :-) > 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. Got it :-) NP BR, Jarkko
