Discuss mailing list

[Rouben <rouben AT rouben.net>]

Hi Erich et al,

My apologies in advance for a wall of text. I also want to repeat that I am in no way a crypto expert, and don't claim to fully understand any of the above, especially the algorithms/math/cryptography behind it, just the high-level concepts and "advanced end-user" level implementation thereof.

First, I was referring to a distributed WoT model by monkeysphere. Their browser extension approach is intriguing and could work for us... the only issue is, browser extensions, especially those that rely on "native messaging hosts" (extra software that needs to be set up in order to interact with the end-user's OS), are a pain in the ass to install. It's more painful than simply installing a CA cert, I think, unless we wrap the browser extension into a super easy installer for each major platform.

Second, I was referring to Blakely-Shamir secret sharing that was available in the commercial and freeware versions of PGP, but doesn't seem to be available in GnuPG (GPG) and Open/LibreSSL. Here's the relevant documentation: https://knowledge.broadcom.com/external/article?legacyId=HOWTO42097

Note, this is not the same as "shared secret", i.e. just copying the private key and sending its copies to each person. More info https://en.wikipedia.org/wiki/Secret_sharing

PGP (the commercial software) did this neatly. In a nutshell this feature allowed to split a PGP private key into N parts, each with its own individual owner and owner's unique passphrase. In order to conduct any kind of crypto operations with this split key (decryption and signing), M out of N owners needed to perform it, where M < N. The way it was implemented was cool too; each owner of a split key piece could perform the operation asynchronously and on their own, and pass on the intermediate output of the operation to the group. Once a sufficient number of owners (i.e. M) performed the operation, the final output (e.g. decrypted text, or signed data/cert) was generated. For example:

ACME Inc has 3 employees (N=3), Bob, Alice and Joe. They create a "split" secret key and each has their own share of the key with its own unique passphrase. They decide on a 2 out of 3 key sharing policy (M=2), where any 2 of them are required to perform secret key operations. The public key is not split, and available on ACME's company website.

Carl, a customer of ACME, uses the public key on the company's website to encrypt a sensitive document and sends it to ACME's public mailbox.

Bob gets Carl's encrypted email, and uses his share of the secret key to produce an intermediate called Bob1. Bob then passes on Bob1 to Alice. Alice's email is set to autoreply that she's on vacation until next week. Bob then passes Bob1 to Joe. Joe, receives Bob1 and decrypts it with his share of the shared secret key. Since 2 shares of the keys were used, Joe obtains the fully decrypted document sent by Carl. Joe then shares Carl's decrypted document with the group.

Here's a "democratic CA" example:

Suppose OpenNIC has 3 elected "cert signers" and a policy where 2 out of 3 of them need to agree to sign the cert. You see where I am going with this? Just replay the Carl, Alice, Bob and Joe example above replacing Carl's document with Carl's intermediate CA cert signing request (CSR) and "decryption" with "signing", and the ACME Inc corporate key with the root CA cert private key. This could be used to allow a group of people to "vote" whether or not to sign a candidate's (Carl's) CA cert with the root CA cert's private key. And yes, you could do this in PGP (not GPG, AFAIK) out of the box to allow an organization to split the responsibility of PGP key owner identity verification among a group of people.

They key features here were that:

1. Any secret (including private/secret key) can be split into a N of M type scenario. This can be achieved with the Shamir/Blakely secret sharing algorithm. An open source implementation of this is called gfshare, and is available as a DEB package on Ubuntu.

2. IMPORTANT: the shares can be used by different people on different machines at different times to produce intermediate data (encrypted?) that can be securely passed around to the individual secret key share holders, so they can use their key shares/parts independently at a time/place convenient for them.

3. Once the sufficient number of shareholders used their shares of the shared secret key, the message is fully decrypted.

4. Presumably none of the shareholders were able to reconstruct the original "split" secret key, i.e. Joe was not able to reconstruct and captire the full secret key from Bob's intermediate message Bob1.

The problem here is that the gfshare implementation won't work, because it can't be used to produce an intermediate output ("partially encrypted") that can be passed on to the remaining shareholders. This *was* possible with PGP. AFAIK neither GPG (GNU Privacy Guard) not Open/LibreSSL offer this out of the box. I'm not sure why, because I think in a CA scenario, the root cert's private key could be "protected" this way.

The man page of gfshare http://manpages.ubuntu.com/manpages/focal/en/man7/gfshare.7.html does offer an interesting scenario that can be used to back up a master GPG private key used to certify its subkeys. Basically the idea is that when you create a GPG key, you have one master key that's only allowed to certify (i.e. edit the key, such as add/edit/remove subkeys, extend validity, etc), and you also have 3 separate subkeys that are used exclusively for signing, encryption/decryption and authentication. This is described in detail here: https://github.com/drduh/YubiKey-Guide in conjunction to using a hardware token, like a YubiKey, to store all the subkeys. The "master" key is stored offline, and is never used on a machine that goes online. In a sense, the "master" key is like the CA Key of your GPG key, while the signing, encryption and auth keys are like the certs you use for specific functions. In theory, instead of storing your master key in cold storage, you could use gfshare to split it up between N places, and securely store each shard in different places. You'd need a certain number of these shards to reconstruct the master key in order to edit your GPG keypair (eg. do this every year to extend its validity). You could also do the same with the revocation certificate for your key and use the same method to reconstruct it if your GPG key ever gets compromised.

In case of personal GPG keys, I understand the above is quite "cypherpunk" level hardcore, but hey, it's nice to know it's possible. In the context of a CA, I think it's quite useful... but alas, I lack the skills/understanding here to be of any further help/use.

Rouben

On Sat, May 23, 2020 at 9:10 AM Erich Eckner <opennic AT eckner.net> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On Fri, 22 May 2020, Rouben wrote:

> You could do a split PGP/GPG key approach, where two people with their own
> individual Yubikeys (or similar device) need to sign the intermediate, but
> we would need to figure out how to convert these signed certs into X.509
> after the fact. I’m not sure if this is even possible, as PGP/GPG has *some*
> X.509 capabilities, I just don’t know if it supports all the extensions
> necessary for a CA intermediate.

I think, this will not work: An X.509 certificate is *one* signature (of
the other key and metadata), while the PGP/GPG scenario, you describe,
sounds like GPGs web of trust - which relies on *multiple* signatures (of
the other key) to verify that key. These two concepts are not
interchangable.

However, the math *should* be possible: Theoretically, one could create a
combined signature in a Diffie-Hellman-like procedure. The only thing, I
don't see, is how one would create the respective private keys, because
they are not independent of each other and the (combined) public key.

That being said: I'm not a gpg nor openssl guru either ;-)

>
> Any OpenSSL/GPG/PGP gurus on here that know of a similar mechanism (split
> private key)?

I have been pondering this a little more and came to the conclusion, that
it might really be better to have multiple such keys. This would
additionally secure against the case, that one of them goes rogue/gets
compromised.

Also it might be worth considering to have multiple Intermediates
(parallel, not serial), so the acme-signing can be trivially distributed
over multiple persons/hosts. But this is rather simple to implement, as we
would only need to sign all those intermediates (regularly) by the root
ca(s).

btw: How would such a per-design-centralized infrastructure (not your
fault, Rouben, but rather X.509's fault) cooperate with the democratic and
decentralized nature of opennic?

>
> Rouben

regards, Erich

P.S.: I'm currently fighting to compile step-cli and step-ca on arm to try
it out for my personal PKI on my raspberry (so far I was using an ugly,
hand-crafted, ssh-based, not-scalable, self-written automatic pki).

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7JIJMACgkQCu7JB1Xa
e1oGChAAvk5TKkGouJEOPtI6WG9M1Pw9MQrPIB46bjSUmumiWexa7wCHvjK7Va54
xfGHryshs44OmVcLM6WhD5+XUQgIOt4uyA6Smdw6ZruGhHHMzXBAOqgq3vT6UBXf
CWHSmU+POgc82TsEqGb0YwixxAO7GOFujtK7q5QVcrk1ZhzUj6VqGHCBjVYRnxe7
CxLyQ8F/hapzuLyrTNABpHVR++8mKDSOgNk+u8ikep3zybx5SebJEHUE7EQnSKpR
UK0anMp/l5jRdiTshgZvImZ/29CinwYl7gjegQtNNkuz750IJpcAI+QXupIFNT8d
6mNT+9j6nLYKpcpMNmL/Gz0HhwRnp5iLEypkWL0iUBW/W3KKsbVzahKGnaqTsz5k
4BfecHAA0BGoD1pTzlUs6t1z6F/jWp0j3DL9eiBSOQbisye45SrlMESG78nJcKDp
TWDJwCUDRyR2QPqiqrL9HZ1GeDPOw3oMAKu6zy5OPG5U63Mw7ObvxiP25RW9R4TZ
TmdGyHLnGy+e1MFlktU9KPgl6Sdsg88kT8gS5JPBtRrm5eFnpCmMI1dU+oigrCY9
uwT9i39ndUHuRqnXSX5YKJjTNM/8hREhQwT1Jt8iA4yeBEcKMCU1tnhetp5+anwe
rud8N8HTz0TzsF3Vh/0MhuYuPiH92VT7KCd2E2yi3oHOPJ9h/qs=
=z9+P
-----END PGP SIGNATURE-----

--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org