On Fri, 2023-04-28 at 14:48 +0000, me@paulapplegate.com wrote:

I don’t know much but is this what you needed.

https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/

https://fedoraproject.org/wiki/Changes/RpmSequoia

Thanks, using Sequoia PGP in Fedora was just to say how I was aware of the library.

More or less, what I was asking is if there is a function or a group of functions that, given a blob of PGP packets, returns the public key, the algorithm, ...

Also, I would like to have a self-contained binary, without shared libraries, and stripping everything that it is not needed.

Thanks

Roberto

Hi Roberto,

Wow, what a comprehensive reference! Thanks a lot for that and even though I still haven't parsed everything it gave me a high level overview of the scope.

On 2.05.2023 11:47, Roberto Sassu wrote:

Ok. Maybe this would have less priority. The first priority would be just reuse Sequoia PGP possibly untouched.

Yep, I agree. Even though you sent some really impressive code fragments my C is a little bit rusty (hehe) and it would take me quite a bit of time to write bindings to all these structs.

If you would be working on that part I'd be happy to fill in any "Sequoia-specific" parts in your Rust code including parsing MPIs and verifying signatures [0].

Thank you for your time!

Kind regards, Wiktor

[0]: https://docs.sequoia-pgp.org/sequoia_guide/chapter_01/index.html

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