GPG smartcard security bypassed by delegated private key

[lrvick]

My PGP private keys exist in only 2 locations:

1. An encrypted backup in a secure location
2. Inside the GPG smartcard on my keyring

I do this because It gives me assurances that no one can steal my private key from memory or disk at any point and decrypt/track/sign on my behalf. Any time I remove my key from a device, I walk away clean with no secrets on disk or in memory. I use many different devices, many of them for short periods of time so this is fairly ideal for me to limit my attack surface.

The current implementation of tracking with the command line defeats this. As best I can tell when I log in via GPG a local private key is created which in turn my GPG key signs and uploads the public key of, verifying I have delegated control of my keybase account to this new device key.

I can then remove my smartcard and perform any keybase operations with this delegated key on this system forever. I can not even remove this key when I am done via the CLI as it is considered my "current device".

I realize to walk away from this system clean I can simply killall keybase and delete my .config/keybase directory but then I have this device hanging around on my public profile that is not actually valid. I must log in with a new device to delete the old one which is an endless loop. I want -no- active devices when I am not actively using them.

Possible solutions to this to address my use case in order of preference:

A: Let me perform keybase operations directly with gpg and by extension my gpg smartcard B: Allow me to use one of the generic AES private keys already on my smartcard C: Continue with existing delegated key implementation with the addition of allowing for on-disk private keys to be bound to my current ip address and expire after N minutes or when I "keybase logout."

Thoughts?

[grempe]

:+1:

[RichJeanes]

keybase deprovision?

[franc0is]

:+1:

[bladealslayer]

+1

[phryneas]

+1

[ghost]

Yes, do it.

[RichJeanes]

Still pretty sure keybase deprovision is the solution you're all looking for. If not, please explain how the deprovision command doesn't fit your needs.

[phryneas]

The problem is only partially that the machine has to be deprovisioned.

The thing is: we have moved away from storing out private keys in a file system or in memory, rather they only exist on a smartcard and every crypto-operation is done on said smartcard.

Moving to keybase defeats that step of securing ourselves as keybase is built on a principle of storing keys on disk and in memory (which we don't trust).

This would be mitigated if keybase were, for example, to use the gpg binary internally, as that binary allows the use of keys on a smartcard for decrpytion, signing and authentication. That is solution A mentioned above.

Your suggestion to use keybase provision would be closer to solution C above, only that we would have to deprovision the key every time we do not use keybase for a few seconds, to give us at least a bit of security loosely resembling the security we currently have per default.

[patrickxb]

You can provision using GPG external commands to sign the statement. With the CLI, when you are provisioning a new device and you select GPG, you will see something like this:

In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key.

You have two options.

(1) Keybase can use GPG commands to sign the installation.

(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted
    keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt' 
    going forward.

Select option (1) and your gpg key will never be stored on disk or in memory. The signed statement that GPG generates will go into your sigchain and you will be all set and you will use per-device NaCL keys for all (non-pgp) operations going forward.

[phryneas]

Yes, this is already better than it was a while ago, when that option did not exist and all that was very finnicky - but this is just for gpg operations.

It isn't really mitigating @lrvick 's problem: he removes the smartcard from his computer, but his computer stays logged into keybase, as keybase internally uses a per-device key that is not really the gpg key.

As I understand it, he wants to be logged into keybase as long as his smartcard is in his smartcard reader and the smartcard is unlocked (without any kind of key touching his memory or harddisk).

[a11enh]

Yes, I must admit that this thread directly addresses my confusion with using the keys made by keybase -v- my gpg hardware key. I feel like some significant level of security was lost with the new device keys -v- using keybase to smooth out gpg functionality. The other option of using other signing/encryption via the smartcard is also a valid alternative- as it keeps the concept of physical security of access to the secret key. I worry that this is a basic difference of opinion choice that keybase has made for its userbase in order to ease difficulties in the new kbfs. Maybe a white-paper on how to keep security for those interested in hardware-side encryption cards/keys? Should we shun all use of KBFS? What needs to be done to ensure only the secret key on the card is used for all operations?

[onlykey]

I too am looking for a solution for this issue. I have this product OnlyKey that supports 32 ECC keys and 4 RSA keys where similar to a smart card the decryption and signing only occurs on the offline hardware. It looks like supporting only offline crypto on the OnlyKey with Keybase client would be possible but there would have to be some way to select to store and use the per-device NaCL keys on the offline hardware instead of on disk. So for my example, I could use one of the 32 ECC key slots to store the per-device NaCL key and then every time a decrypt or sign operation is requested in the app it would send a request with the KEY ID and the ciphertext to the OnlyKey and then the plaintext back to the app.

Has there been any progress in supporting 3rd party USB tokens like this? Anyone want to work together on getting this working?

[maxtaco]

First off, I think the title of this issue is a little too strongly worded. I don't think any security has been "bypassed." If you use a GPG smartcard to provision your first device, you are signing a statement, saying some other key can be used with Keybase, and you, the owner of the smartcard, are OK with this delegation. It doesn't seem to me that the security of your GPG smartcard is downgraded by this delegation. If you decide in the future that you no longer care for this delegation, then you can use that same GPG signing key to revoke that signature. You can use the delegated key to revoke itself (via deprovision). Etc. No secrets have been exfiltrated.

Zooming out a bit, thanks everyone for their discussion here. We're going to mark this issue as "won't fix." We made a decision a few years back to pursue a key model different from GPG's for our chat, KBFS and git products. We think this key model is simpler for people to pick up, and to use efficaciously over time, especially non-experts.

By now we're over 2 years in, and we think it's been quite successful. There are three major successes we can point to: (1) people "get" the idea of a one-to-one correspondence between devices and keys, and therefore, they don't need to think about "keys" any more; (2) all of our products work well on mobile (which is hard to say of any hardware-based GPG solution); and (3) our users have good protections against data loss. As security aficionados, we think a lot about how not to get our data stolen by a malicious adversary. That's the "yin." But there's a "yang" here, which is that encryption is a very powerful foot-cannon. It is so easy for people to make their data inaccessible to everyone, including themselves. They can do that by losing their smartcard, or by forgetting their pin, or just by misconfiguration. For many people, losing their data is a bigger concern than having it stolen because the former is so much more likely to happen. So one of the major successes of our new key model is that users have to lose all of their devices at once before they lock themselves out of their data. We think this a big step forward, but requires the exact mechanism that the OP opposed.

We feel like we can make the most impact if we extend end-to-end crypto to as many people as possible. And not some watered-down version of end-to-end crypto that doesn't work for teams above a certain size, or that trusts a central server for key exchange, or in which the server has some backup of your key in case you lose it. No, actual end-to-end crypto, where if some bad guy comes into our office and asks us to break into a chat or recover an encrypted file, there is nothing we can do. As a result of this rather ambitious mission, we have to focus our efforts and can't accommodate all use patterns of experts, regardless of how well-reasoned they are.

If the GPG smartcard is the model people in this thread truly want, we'd encourage you to just use the Keybase website shim, which allows you to prove social identities and to follow other users, without any device-specific keys. Then you can use the gpg CLI for doing all of the things you always used it for, and Keybase is, for you, is little more than a key lookup.

[junderw]

Good answer.

[a11enh]

I appreciate the discussion, maxtaco! I think this gives voice to the implementation choices that keybase made, and in fact also addresses the question I had about hardware key usefulness as well.

I agree that hardware keys are difficult to use, especially in light of hardware limitations that are only now being dealt with in iOS and NFC ubikey functionality (would be great to implement that in the app on iOS in the future!). But ultimately there is a trade off. (Those who run airgaps are painfully aware of the loss of connectivity.)

Thank you also for addressing what keybase is focused on accomplishing. I hope that keybase continues to grow and is successful!

Thanks for addressing the questions and helping to answer some of the points I was confused about as well.

[lrvick]

(1) people "get" the idea of a one-to-one correspondence between devices and keys, and therefore, they don't need to think about "keys" any more;

I do not think teaching people to not worry about controlling their own keys because some company is going to do it for them really progress. Teaching people to do this just sets them up to be exploited. Projecting the idea that you -had- to violate standards and make a centralized proprietary SaaS in order to make encryption easier is a stretch considering OpenKeychain and others didn't need to do this to make their user friendly GPG toolchains.

(2) all of our products work well on mobile (which is hard to say of any hardware-based GPG solution);

I use my GPG smartcard on my phone for email, ssh, and password management all the time. All use cases are well supported via OpenKeychain and a number of apps that consume it. When you support open standards, these sorts of integrations happen easily. Amusingly, OpenKeychain even optionally imports keys from Keybase, then does everything from there with standards.

(3) our users have good protections against data loss. As security aficionados, we think a lot about how not to get our data stolen by a malicious adversary. That's the "yin." But there's a "yang" here, which is that encryption is a very powerful foot-cannon. It is so easy for people to make their data inaccessible to everyone, including themselves. They can do that by losing their smartcard, or by forgetting their pin, or just by misconfiguration. For many people, losing their data is a bigger concern than having it stolen because the former is so much more likely to happen. So one of the major successes of our new key model is that users have to lose all of their devices at once before they lock themselves out of their data. We think this a big step forward, but requires the exact mechanism that the OP opposed.

Implying you needed to throw away all standards to avoid key loss is a really bad faith argument. I exclusively use smartcards for all my keys. I have mutiple smartcards with the same key content. I have offline backups of my keys. I have a sharded version of my keys spread to several friends around the world who can help me even if I ever get amnesia. Nothing was stopping you from making flows like this user friendly. I have documented the manual way to do this in great detail: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/GPG/Advanced_Setup.md

I have deployed these strategies at three companies now for hundreds of people. They work. Many people with lost yubikeys that were able to self recover. The biggest gap is nicer UX to replace dozens of CLI commands which is the thing I think Keybase excels at and could help with.

We feel like we can make the most impact if we extend end-to-end crypto to as many people as possible. And not some watered-down version of end-to-end crypto that doesn't work for teams above a certain size, or that trusts a central server for key exchange, or in which the server has some backup of your key in case you lose it. No, actual end-to-end crypto, where if some bad guy comes into our office and asks us to break into a chat or recover an encrypted file, there is nothing we can do. As a result of this rather ambitious mission, we have to focus our efforts and can't accommodate all use patterns of experts, regardless of how well-reasoned they are.

Virtually all of Keybases use cases could be supported by TEEs, and smartcards in ways that don't lock users into your platform. You guys have so many great UX ideas but it is hard for anyone with an applied cryptography background to endorse your current implementations. Keybase is in my opinion one big step forward with user experience and accessibility, and two backwards in standards and safety. We can have both!

I'll grant that there is no way to add arbitrary social media UIDs to PGP keys as the standard exists today. This was a novel idea (and the one part of Keybase I actually use). I did however fail to locate any post to the PGP working group mailing list by Keybase to propose a new key packet type to implement this in a standard decentralized way. A peer on my security research team, @kellerfuchs , has attempted to do this, and would love support: https://mailarchive.ietf.org/arch/msg/openpgp/HcR2tUSEOfOVNTE1pdScSGo5FHc

Barring that, virtually all other Keybase features could totally be supported by existing standards and smartcards. It is not too late to adjust course here. Please don't be the IE6 of cryptography that pulled masses away from standards and the ability to properly co-exist with other tools that follow them. It never works out and just slows down progress for everyone in the long run.

Should you ever want to pursue some of your use cases in a fully open source decentralized way that does not create lock-in for your users, I'll happily provide consulting for free and know several others that would too.

[bettyvschmartz]

I do not think teaching people to not worry about controlling their own keys because some company is going to do it for them really progress. Teaching people to do this just sets them up to be exploited. Projecting the idea that you -had- to violate standards and make a centralized proprietary SaaS in order to make encryption easier is a stretch considering OpenKeychain and others didn't need to do this to make their user friendly GPG toolchains.

Couldn't agree more. I am using @onlykey and wanted to use a purely offline key to interact with Keybase. Whilst the UI/UX of Keybase is a step forward, this is a step backwards in terms of security, and I see no reason that both can't be achieved.

First off, I think the title of this issue is a little too strongly worded. I don't think any security has been "bypassed."

I agree that security hasn't been bypassed but it's certainly sub-optimal in comparison to the OPs use case. This is especially surprising for 'security aficionados'. I understand the argument regarding trade-offs but you must see evidence, with the increasing adoption in cryptocurrency, more and more users are taking control of their own keys? They are doing so using FOSS tools, often with simplified UI/UX. It's folly to claim that you must trade one for the other.

I may be misinformed but it doesn't seem much of a stretch to do this, given you already interact with the GPG binary.

-- bvs