Feature Request: Pluggable Backend System for Smart Card Secret Storage

[slynnda]

Hey!

First off, KR is amazing and I'm very pleased with where the project is going. I've been looking for something like this for a while and it's fantastic. The feature set and user experience are great.

If I may, I'd like to suggest a possible feature that I think would be useful:

As of right now, both the private keys for both SSH and PGP are stored in the phone in such a manner that they can never leave the device. While this is very cryptographically secure, it would be useful I was able to store my keys on say, my Yubikey, in smart card configuration. In this manner, the Yubikey would act as a kind of storage backend that could be plugged into my phone to authenticate SSH requests and/or generate the appropriate type of PGP sub-keys needed on the phone.

In this manner, I would be able to create air-gapped backups of my keys without having to worry about having multiple devices with Krypton installed. If I lose my phone, I can re-generate the appropriate credentials on a new phone without too much pain.

I understand the existing cryptographic and philosophical approach you've taken by preferring multiple, independent devices their own unique key pairs. For business with multiple people who can act as key administrators and the budget to buy as many devices as they require, it's not prohibitively expensive to use this approach.

However, as an individual working private projects, it's much less practical to have multiple smartphones on hand and/or in secure physical storage like a safe or lock box.

Would a pluggable backend system for the storage of cryptographic secrets in smart cards be something worth a larger conversation?

[agrinman]

Thanks for the thoughtful feedback @slynnda!

I think this is a sound way to backup private keys (since you don't need an entirely separate phone). It seems like it would be tough iOS/Android device to talk to a yubikey over usb -- any idea how to do this? We don't have time right now to dig into this right now but perhaps at some point down the line.

Another way to do backup with yubikeys is just to generate separate key pairs and provision the backup key to have access to the relevant services.

[slynnda]

@agrinman, thanks for the quick response!

Currently, Android integration with Yubikey is pretty slick, since Yubico has released the Yubikey 4C and Yubikey NEO.

• The Yubikey 4C is identical to the Yubikey 4, save that it's USB-C, so it will work with newer models of Android phones like the Pixel series (I have a Pixel 2 XL). • The Yubikey NEO actually supports NFC, which is supported on quite a few Android devices.

To give you an example of an existing workflow I've been using that's similar to what I think would be cool for Krypton/KR, I'll explain how I'm managing my TOTP/HOTP credentials:

Yubico has a cross-platform -- except for iOS (I'll explain a little farther down) -- application called Yubico Authenticator.

This application is pretty slick because it's allowed me to decouple the storage of my TOTP secrets from a powered, network-connected device, like my Pixel, and store them instead on Yubikeys. I actually wrote an article for the company I work for that gives an example of how you can use this app to manage MFA for your AWS accounts, which you can find here if you're curious.

As it currently stands, I'm able to store the same TOTP secret information for multiple accounts onto multiple keys, so I can keep backups really easily. The TOTP codes only get generated by the Yubico Authenticator application when I've inserted my Yubikey into the device (at which point the Yubikey is powered). This works both via NFC for the NEO and directly inserting the 4C into the USB port on my Pixel.

Part of the reason I moved over to Android is actually so that I could do this. I spent quite a while looking into the iOS support for USB-C and NFC integration, and it's not very good yet. Apple only recently exposed the NFC API to app developers, even though it's been supported by their hardware for quite a while. This is also the reason the Yubico Authenticator application is not offered in the App store.

On Android, I think there are two general user stories this feature could enable:

User already has an SSH key and/or PGP key they want to use with Krypton

In this case, when configuring their Krypton device, they could simply plug their already-configured Yubikey into the phone or use the phone's NFC feature. You could generate a sub-key with the appropriate privileges that gets stored on the phone which is able to create another sub-key on each of the devices.

When the user wants to sign a commit or whatever, they'd get a prompt to authenticate to Krypton with the secret on their Yubikey prior to being presented with the screen that gives them the option to accept, reject, the signing request.

Another way it could work is that you actually give the sub-key you generate on the phone certification permission and possibly a revocation certificate, so that they Yubikey isn't even required, but can be used to regenerate/revoke/rotate the sub-key on the phone.

User does not have an existing SSH key and/or PGP key they want to use with Krypton

In this case, it would be a pretty straight-forward process of generating the secret keys in Krypton, generate the subkeys, and exporting them to the attached Yubikey. I think the rest of the workflow would be the same?

Granted, this doesn't really have to be a Yubikey-specific thing. It could be any smart card that is compatible with the phone and implements the PKCS-11 interface, I think.

What are your thoughts?

[slynnda]

@agrinman, I'm happy to do some of the research and design legwork on the idea if you'd like.

[agrinman]

@slynnda cool blog post! If we were going to do something like this I think the first low-hanging fruit is to allow key import in Krypton, and then move to key backup (perhaps only to a smart card like device). The should address 99% of cases as you could now use a yubikey or your flavor of smart card to hold on to the Krypton key as a backup, and also restore it to a new phone if you lose yours. I'm not sure if abstracting it to the key storage backend level makes sense.

[slynnda]

@agrinman, sorry for the long delay in getting back to you on this.

Thanks for the kind words about the post. I agree with you about key import being the first step here. Is this something you'd like help prototyping? I'm happy to take a whack at it.

[donjaime]

We would like to adopt something like Krypton for our engineering team. We love what you have built so far! But a few things have kept us from jumping in.

Being able to tolerate a dead or lost phone is critical for us. But provisioning a second set of keys and installing them everywhere via kr transfer makes it harder to audit and keep track of authorized keys across systems since we would essentially need 2 or more of everything. That kind of meta-data proliferation adds overhead, and has knock on effects like making revocation a bit more complicated.

It also doesn't deal well with provisioning new hosts. If your backup phone is locked away (as it should be) then it would seem that one quickly ends up with skew between devices wrt which public keys are installed unless you have a mechanism for always installing them and revoking them in pairs.

Restoring a krypton device using an air-gapped yubikey (of which you could have multiple copies) would be fantastic. Not needing to distribute and manage multiple sets of credentials is a good thing. Would love to see this feature implemented!