On Thu, 2023-07-13 at 10:31 +0200, Wiktor Kwapisiewicz wrote:
Hi Roberto,
Not sure if you're following but I've been slowly working towards Kernel Crypto Sequoia backend:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1030 https://gitlab.com/sequoia-pgp/sequoia/-/tree/wiktor/add-kernel-crypto
Hi Wiktor
thanks for taking care of this! I should have checked the Sequoia PGP development more closely.
Just an update on my side.
The kernel maintainers are not sure yet we would be able to get a fully isolated process in user space handling kernel workloads (in this case to convert the PGP keys and signatures into a format undestood by the kernel).
Without this guarantee, I kind of moved a bit the target, i.e. assuming that the conversion from PGP to kernel format is happening in a trusted environment, such as the vendor premises when the Linux kernel is built.
That is sufficient to achieve the goal of adding the PGP keys of the distribution as a new trust anchor to the kernel.
For signatures, the digest is calculated in the kernel. Altering a PGP signature at run-time has the only consequence of rejecting the data to verify. Thus, the signature conversion can happen in an untrusted environment.
Ok, so now the conversion part.
I changed a bit the kernel format to be more generic. It is Type- Length-Value (TLV). The purpose of the format and the defined fields is to fill the kernel structures public_key and public_key_signature. But there are additional fields, like the additional PGP data required to verify the signature. I added a field for that (SIG_DATA_END).
The original PGP implementation in the kernel was calculating again the fingerprint. However, maybe after all that is not even necessary, we can use the last 8 bytes extracted from the packet as key index.
The closest tool that can be used for converting PGP keys and signatures seems to be sequoia-sq. I was trying to modify this file:
https://gitlab.com/sequoia-pgp/sequoia-sq/-/blob/main/src/commands/dump.rs
but my Rust expertise is very limited..
So, I decided to modify gpg (in C) instead. I was much faster. Please have a look at the last two patches of this patch set:
https://lore.kernel.org/linux-integrity/20230706144225.1046544-1-roberto.sas...
They are basically filling a header:
struct uasym_hdr { __u8 data_type; __u8 _reserved0; __u16 num_fields; __u32 _reserved1; __u64 total_len; } __packed;
and an entry for each field we need to send to the kernel:
struct uasym_entry { __u16 field; __u32 length; __u8 data[]; } __packed;
For keys, we are sending these fields:
KEY_ALGO KEY_KID0 (the last 8 bytes of the fingerprint) KEY_DESC (can be anything, I chosen PGP: <last 4 bytes of fingerprint) KEY_PUB
Unfortunately, there is the additional complexity of converting the RSA key to the ASN.1 format (sequence of INTEGERS). I added a stripped down version of the code to encode the key with mpis_to_asn1_sequence() and asn1_encode_length().
For signatures, we are sending these fields:
SIG_KEY_ALGO SIG_HASH_ALGO SIG_ENC SIG_KID0 SIG_DATA_END SIG_S
So, to summarize, everything that I would need in the latest iteration of the kernel patches is a new option of the sequoia-sq command to convert PGP keys and signatures to the new kernel format.
And all was fine but we hit a major roadblock: it seems asymmetric operations are not available in user-space due to some patches not being upstreamed even though most of them look rather benign: https://github.com/smuellerDD/libkcapi/tree/master/kernel-patches/4.15-rc3/a...
Source: https://github.com/smuellerDD/libkcapi/issues/164#issuecomment-1633783571
Is this something you could help us / kcapi author with? The author says their patches were vetoed "because it was considered that it is not needed" and I think we've got a solid case here.
I understand kernel maintainers might not want new functionality, unless it is really needed. There would have been a concrete case with my trustworthy User Mode Driver solution, as it would have avoided to link other complex crypto libraries.
Without the trustworthy User Mode Driver, and doing everything in user space in a trusted environment, maybe the kernel extension would not be needed (sorry, I should have updated you while implementing the new solution).
Let me know what you think about the new developments.
Thanks!
Roberto
I'd do it myself but I think you're already deeply immersed in kernel development and it could go faster with you. If not, please do tell.
Thanks for help in advance!
Kind regards, Wiktor
On 28.04.2023 16:16, Roberto Sassu wrote:
Another point would be to avoid external dependencies, like a crypto library, and to use the kernel Crypto API instead (through socket(AF_ALG) in user space). Not the highest priority (as it would require to rewrite some parts of your library), but nice to have.
Devel mailing list -- devel@lists.sequoia-pgp.org To unsubscribe send an email to devel-leave@lists.sequoia-pgp.org