From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Jarkko Sakkinen <jarkko@kernel.org>,
dhowells@redhat.com, dwmw2@infradead.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
zohar@linux.ibm.com, dmitry.kasatkin@gmail.com,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com
Cc: linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org, pbrobinson@gmail.com,
zbyszek@in.waw.pl, wiktor@metacode.biz,
devel@lists.sequoia-pgp.org, gnupg-devel@gnupg.org,
ebiggers@kernel.org, Jason@zx2c4.com, mail@maciej.szmigiero.name,
antony@vennard.ch, konstantin@linuxfoundation.org,
James.Bottomley@HansenPartnership.com,
Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [RFC][PATCH v3 0/9] KEYS: Introduce user asymmetric keys and signatures
Date: Fri, 21 Jul 2023 09:04:04 +0200 [thread overview]
Message-ID: <21cd4127cee2d920ffab7576e9a6359ec0988b8d.camel@huaweicloud.com> (raw)
In-Reply-To: <CU76KX3XPZN9.V9GU2ZZKVKO@suppilovahvero>
On Thu, 2023-07-20 at 20:38 +0300, Jarkko Sakkinen wrote:
> On Thu Jul 20, 2023 at 6:32 PM EEST, Roberto Sassu wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> >
> > Define a new TLV-based format for keys and signatures, aiming to store and
>
> "type-length-value (TLV) based"
Ok.
> > use in the kernel the crypto material from other unsupported formats
> > (e.g. PGP).
>
> Where's the motivation part and where is this defined?
Ah, thanks for the reminder. Will add it in the next version.
The motivations are:
- Avoid adding complex parsers in the kernel that might introduce
vulnerabilities
- Avoid adding support for key and signature formats that some consider
weak
That was basically the summary of the review of my attempt to add
support for PGP keys and signatures in the kernel.
This patch set adds support for only one format, which other formats
are converted from.
This is useful for the mere extraction of crypto material, and use it
with the kernel crypto API.
If there is a trust relationships between the original keys, converting
keys would lose the ability to verify that trust relationship.
Example
Suppose that there is a PGP key in the built-in keyring, and that
signed another PGP key.
If I want to add the second PGP key to the secondary keyring, I would
have to verify the signature of that key with the first key.
But the signature is on a PGP packet, so if the kernel verifies that
signature it would have also to ensure that the public key extracted
from the signed packet is the same as the converted key.
Originally I thought that we could do the conversion in a fully
isolated user space process (trustworthy User Mode Driver), so that
there is the guarantee that the key has not been modified during the
conversion. However, since it is difficult to achieve perfect
isolation, that approach has been put on hold.
So, at the moment, verifying trust with user asymmetric keys is not
possible, but this is not a problem with my use case, as a Linux
distributions can embed in the kernel all their (converted) public keys
directly usable for signature verification.
Thanks
Roberto
prev parent reply other threads:[~2023-07-21 7:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 15:32 [RFC][PATCH v3 0/9] KEYS: Introduce user asymmetric keys and signatures Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 1/9] lib: Add TLV parser Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 2/9] crypto: Export public key algorithm information Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 3/9] crypto: Export signature encoding information Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 4/9] KEYS: asymmetric: Introduce the user asymmetric key parser Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 5/9] KEYS: asymmetric: Introduce the user asymmetric key signature parser Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 6/9] verification: Add verify_uasym_signature() and verify_uasym_sig_message() Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 7/9] KEYS: asymmetric: Preload user asymmetric keys from a keyring blob Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 8/9] KEYS: Introduce load_uasym_keyring() Roberto Sassu
2023-07-20 15:32 ` [RFC][PATCH v3 9/9] ima: Support non-PKCS#7 modsig types Roberto Sassu
2023-07-20 15:32 ` [RFC][GNUPG][PATCH v3 1/2] Convert PGP keys to the user asymmetric keys format Roberto Sassu
2023-07-20 15:32 ` [RFC][GNUPG][PATCH v3 2/2] Convert PGP signatures to the user asymmetric key signatures format Roberto Sassu
2023-07-20 17:38 ` [RFC][PATCH v3 0/9] KEYS: Introduce user asymmetric keys and signatures Jarkko Sakkinen
2023-07-21 7:04 ` Roberto Sassu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21cd4127cee2d920ffab7576e9a6359ec0988b8d.camel@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Jason@zx2c4.com \
--cc=antony@vennard.ch \
--cc=davem@davemloft.net \
--cc=devel@lists.sequoia-pgp.org \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=gnupg-devel@gnupg.org \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=paul@paul-moore.com \
--cc=pbrobinson@gmail.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=wiktor@metacode.biz \
--cc=zbyszek@in.waw.pl \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).