A use case for #OpenPGP #signing that would combine best of #Yubikey and a #TPM2 chip:

1. A/S/E subkeys inside Yubikey.
2. C (#certificate) key as TPM2 ASN.1 blob.

The C key can be tied a to single chip during its creation. If someone gets a copy it is useless without that exact chip.

For the sake of defense in depth, a maintainer would keep that exact blob still in USB stick.

This scheme would be pretty airtight as even certification creation while the machine is online, would have quite low risks. E.g. if the ASN.1 blob is stolen while online, the key is useless by itself.

So in the context of #Linux #kernel #PGP #maintainer #guide this would make the whole process way more relaxed and convenient with the help of TPM2 chip.

How we deal with subkeys that part is smooth but there's still room for improving The Maintainer Experience when dealing with your Certification key :-)

I will work on user space shenanigans for this maintainer flow upgrade after this patch set is finished: https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/T/#t. I.e. find good route for gnupg to access the TPM2 (RSA4096/Curve25519) key, which is imported OpenPGP cert key...

100% guaranteed to be part of my presentation, if gets accepted to the kernel summit 😉

If that gets accepted Ill aim for demo on this too 💣💣💣

@duxsco TPM2 is simple and standardized keystore/smartcard framework in this context and for cert-keys its non-mobility is an asset. For subkeys yubikey is super-convenient :-)

It is those overcomplex frameworks that Intel and IBM are pushing that make it look complex with their command arbitrators etc.

TPM2 itself is in principle same as Yubikey or #Nitrokey but with a standardized binary protocol and non-mobility ;-)

I started this weekend from scratch to do a completely new streamlined and dead simple tools for using the chip for fun and profit:

- https://crates.io/crates/tpm2_cli
- https://crates.io/crates/tpm2_call

I know what would work for user because I am a user as I need to test all the kernel patches with IBM/Intel crap... The first two commands are like top picks from my most hated list in the aforementioned stack done right :-)

@duxsco TPM2 does have already 25519 supported so it can communicate with SSH and PGP sheanigans quite nicely

@duxsco

NOT true. TPM_ECC_CURVE_448 exists in the TCG algorithm registry. Table 5.1 in this same specifications enumerates ECC curves supported by TPM firmware (or in the spec TCG “TPM 2.0 Library”) interface.

Sometimes features can even land through firmware updates. especially for fTPM’s in Intel, ARM (via SMC AMD CPU’s this is feasible approach.

I’ve been also started to lobby the idea of getting P256K1 to the registry based on principle of equally feasible playing field for established corporations and growth companies of variable side (aka startups):

1. Corporates need to have their NIST curves.
2. There’s a critical mass of blockchain associated startups, in varying levels. So to have working capitalism also “Bitcoin curve” should be there.

I’m going to also write P256K1 software primitives to Linux kernel to enable more secure options for managing that sort of assets.

I do it part of my role as Linux kernel key-ring co-maintainer. My job is to identity widely use key types, enable them and call it a day, i.e. create equal capitalist market place for every actor.

I would enable P256K1 even if I hated blockchains by guts because it is my freaking job :-) Liking and disliking about stuff is part of leisure time (or when getting drunk which is part of leisure time ;-)).

@duxsco It is pretty shameful that so common curve P256K1 is not already there.

I could be wrong but is P256K1 even used as part of #Estonia social security number blockchain? Maybe I could get a state level actor to help me to get that curve in :-)

I spent some time ago hours going through Est government pages looking for exact algorithms in their blockchains but all I could find was typical blockchain whitepaper/markerting crap, how great Estonia is and 200 years ahead rest of the world, and I like all that and admire but... ... ... could you also put the boring stuff i.e. ciphers used there ?

@jarkko @duxsco

The identifier has only been reserved. It's to my knowledge no support for actually using this as the spec doesn't support the signature scheme it needs.

@Foxboron @duxsco ok so does it have shorter bit length than 255bits?
Less bits => new signing algorithm ;-)

@Foxboron @duxsco

OK so this is how these are:

• K1/R1: {256,384,521} bits finite field: ECDSA + SHA-{256,384,512}
• 25519: 255 bits finite field: EdDSA + SHA-512
• 448: 224 bits finite field: EdDSA + SHAKE256

They are all in the TCG Algorithm Registry so it is up to firmware updates to support it. TCG specifications have all assets to implement 448 signing (I just checked).

#factcheck

@jarkko @duxsco

The TCG Algorithm Identifier doesn't matter for the TPM implementations, it's only a list for TCG specifications.

All of these lack in the actual TPM specifications, which means they are not supported and wont be implemented.

@Foxboron @duxsco that's a shame but at least it. can be now supported. i.e. could be worse ;-) K1 is not even the registry and getting to the registry is mandatory requirement for anyone to consider a new algorithm.

For kernel maintainers RSA + NIST does provide quite a good coverage for certificate keys, so as an opt-in feature, not required but can ease the workflow, it is level up even with just those two curves (and that was anyway my original take) :-)

@Foxboron @duxsco
Morten just a summary

1. TPM's containing TCG algorithms for Ed curves are rare, or perhaps even non-existent.
2. Still, having `TCG_ECC_CURVE_ID` matters obviously because it hard requirement for having the implementation. 0.1% so much better than 0.0% odds, right?

@jarkko @duxsco @jarkko egov here in Estonia I based on KSI blockchain, perhaps you can find hints here https://github.com/guardtime/libksi to my knowledge, big portion of Estonian egov is opensourced see here https://github.com/e-gov

@jarkko @duxsco @jarkko not mentioning there is no such thing as social security number, perhaps you mean Personal Id (isikukood) and this unique identifier is covered by EV ST 585-90 standard

@janantos @duxsco yep, well IMHO ID is always also a number ;-) Anyway, thanks a lot could not find it myself! Might become essential if the curves turn to be right :-)

@janantos @duxsco OK, so if my information is correct KSI uses the NIST curve, i.e. P256R1 and because of that ECDSA signatures. Bitcoin also uses ECDSA but with a different curve P256K1.

Meaning that even my in progress patch set can sign those when the private key is managed by a TPM chip [1]. Anyway good to know.

[1] https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/T/#t

@duxsco @janantos

Do want to slander our neighbor nation but I’m bit skeptical towards claim that Estonia had its first blockchain in 2007.

Bitcoin paper came out in 31st of October, 2008, so possible conclusions:

1. Bitcoin was not the first blockchain like within the metrics for such data structure that the paper defines.
2. KSI has some of the characteristics of those defined in the original Bitcoin paper but is not an “actual” blockchain.

Without better knowledge, bullet 2 is pretty good base assumption. Or who knows, perhaps Satoshi Nakamoto is an Estonian citizen or a group of citizens.

@jarkko @duxsco @jarkko I don’t know, we can discuss if KSI is actually blockchain. For sure it’s developer Guardtime saying KSI was first developed in 2008 and e-Estonia for com website mentioning that KSI was developed after Estonias experience with the 2007 cyber attacks. I am referring http://e-estonia.com/solutions/cyber-security/ksi-blockchain/ but you are right that the infographic on the page refers to 2007.

@jarkko @duxsco however based on wiki, first blockchain like protocol was described in 1982 by David Chaum and subsequently worked in 1991 by Stuart Haber and W. Scott Stornetta. I believe the Bitcoin blockchain is the first decentralised one. So there is good chance they are not bullshitting.

@janantos @duxsco Yep, I get a gut feeling that marketing department has mixed up blockchain and revocable ECDSA signature ;-)

@janantos @duxsco Ah, right I always connect the whole to the distributed version! So it is taxonomy dependent how you argue about the topic. Thanks, I did not know nothing about David Chaum's past work. I will read that...

@jarkko @duxsco actually you forced me to dig now and I just found that Merkle Tree (hash tree) is going as deep as 1979 when in was patented.

@jarkko @duxsco I think they mix together data structures using hash trees

@janantos @duxsco OK, Bitcoin's so called "proof of work" is also based on Merkle tree per TX block.

@jarkko @duxsco and so ethereum, and million other things including file systems. The blockchain today is so vaguely defined term. In this context we can actually have very long “dispute” whether KSI is blockchain or not. The only thing we can agree is, it is widely used also outside Estonia.

@janantos @duxsco I think it is a great invention to use elliptic cryptography for social id's no matter how you categorize it ;-)