Reading public key portion of asymmetric keys

Reading public key portion of asymmetric keys

[James Prestwood]

Hi,

Unless I'm missing something it does not seem possible to read back the 
public key portion of an asymmetric key to userspace once added to the 
kernel. I have a use case where two separate applications need to 
perform crypto operations using the same private/public key pair and for 
added security it would be convenient to add the key (or load from TPM) 
once and pass around a key ID rather than the keys themselves.

One of the things I need is to create and sign a CSR. To create the CSR 
I need the public key contents which can't be obtained from the key ID.

To solve this problem I would propose adding a "read" operation to the 
asymmetric key type, but limiting it to only reading the public key 
portion of the key (if it exists). Alternatively a entirely new 
"read_public" keyctl API could be added as well, but re-using the 
existing read seemed more straight forward. Adding this seems easy 
enough, but I wanted to get an idea if this is something that would be 
accepted upstream or if others had better suggestions.

Thanks,

James

Re: Reading public key portion of asymmetric keys

[bauen1]

Hello,

I just wanted to chime in, that I would also be interested in this.

On 9/30/24 8:40 PM, James Prestwood wrote:
> Unless I'm missing something it does not seem possible to read back the public key portion of an asymmetric key to userspace once added to the kernel.

I haven't found a way to do so either, in some cases (x509 ?) the fingerprint (of the subject identifier ?) might be displayed in /proc/keys, but not the public key for an asymmetric key loaded into the keyring.

> I have a use case where two separate applications need to perform crypto operations using the same private/public key pair and for added security it would be convenient to add the key (or load from TPM) once and pass around a key ID rather than the keys themselves.

My use case is loading a key into the keyring (tpm, stored on disk or generated ad-hook - shouldn't matter) as part of a request-key program, and giving only this key back to the application.
The application can then request a certificate in a separate request_key operation.
As a result, the application itself never has access to the raw key material, but gets a usable asymmetric key along with a certificate.

Now ideally I would need the following things:

- Verify that the key the application is requesting a certificate for is genuine. I.e. hasn't been loaded by the application itself.
- Read the public key from a loaded key to sign a certificate for it.
- Ideally some existing integration, e.g. an openssl provider to utilize the key with the pkey_* operations. Unfortunately I haven't found any, if there are, I'd love to know about them :)

Currently I work around this by having a keyring under the root user keyring, where I link every generated/loaded key, so I can later check that it is in fact a genuine key.
Additionally I store the public key, encoded as OpenSSH key, in the description of the key.
It's not amazing, but it works as a proof of concept and doesn't require any modifications to the kernel.

> One of the things I need is to create and sign a CSR. To create the CSR I need the public key contents which can't be obtained from the key ID.

For pretty much this exact purpose.

> 
> To solve this problem I would propose adding a "read" operation to the asymmetric key type, but limiting it to only reading the public key portion of the key (if it exists). Alternatively a entirely new "read_public" keyctl API could be added as well, but re-using the existing read seemed more straight forward. Adding this seems easy enough, but I wanted to get an idea if this is something that would be accepted upstream or if others had better suggestions.

I don't really have any input for the API, but it might be worth considering if the ability to read out the public key of an asymmetric key would benefit or hurt some of the existing users.
Currently you require access to a key to perform the pkey_verify operation, potentially triggering an LSM or audit log (?), but if you allow reading out the public key, you could e.g. check a bunch of files against a trusted key without triggering e.g. audit logs for these verify operations.

Unfortunately I'm not sure if I'll have the time to implement a proof of concept patch, but I would certainly be willing to help test one.

Thanks.

-- 
bauen1

Re: Reading public key portion of asymmetric keys

[Jarkko Sakkinen]

On Mon Sep 30, 2024 at 9:40 PM EEST, James Prestwood wrote:
> Hi,
>
> Unless I'm missing something it does not seem possible to read back the 
> public key portion of an asymmetric key to userspace once added to the 
> kernel. I have a use case where two separate applications need to 
> perform crypto operations using the same private/public key pair and for 
> added security it would be convenient to add the key (or load from TPM) 
> once and pass around a key ID rather than the keys themselves.
>
> One of the things I need is to create and sign a CSR. To create the CSR 
> I need the public key contents which can't be obtained from the key ID.
>
> To solve this problem I would propose adding a "read" operation to the 
> asymmetric key type, but limiting it to only reading the public key 
> portion of the key (if it exists). Alternatively a entirely new 
> "read_public" keyctl API could be added as well, but re-using the 
> existing read seemed more straight forward. Adding this seems easy 
> enough, but I wanted to get an idea if this is something that would be 
> accepted upstream or if others had better suggestions.
>
> Thanks,
>
> James

Missed earlier (CC to dhowells).

BR, Jarkko

Re: Reading public key portion of asymmetric keys

[Jarkko Sakkinen]

On Fri Nov 8, 2024 at 9:44 PM EET, Jarkko Sakkinen wrote:
> On Mon Sep 30, 2024 at 9:40 PM EEST, James Prestwood wrote:
> > Hi,
> >
> > Unless I'm missing something it does not seem possible to read back the 
> > public key portion of an asymmetric key to userspace once added to the 
> > kernel. I have a use case where two separate applications need to 
> > perform crypto operations using the same private/public key pair and for 
> > added security it would be convenient to add the key (or load from TPM) 
> > once and pass around a key ID rather than the keys themselves.
> >
> > One of the things I need is to create and sign a CSR. To create the CSR 
> > I need the public key contents which can't be obtained from the key ID.
> >
> > To solve this problem I would propose adding a "read" operation to the 
> > asymmetric key type, but limiting it to only reading the public key 
> > portion of the key (if it exists). Alternatively a entirely new 
> > "read_public" keyctl API could be added as well, but re-using the 
> > existing read seemed more straight forward. Adding this seems easy 
> > enough, but I wanted to get an idea if this is something that would be 
> > accepted upstream or if others had better suggestions.
> >
> > Thanks,
> >
> > James
>
> Missed earlier (CC to dhowells).

Right *obviously* to linux-crypto and Herbert! And people/lists relevant
(at least according to MAINTAINERS file).

BR, Jarkko