[Feature] : key distribution

[awilkins]

This Infoworld article that mentions Jak notes that

One member of the team downloads the source code from the code repository and receives the keys via an out-of-band method, which might be as fast and loose as a plaintext email, chat message, USB stick, or sticky note.

... but of course, you still need to do this to distribute the key to decrypt the in-repo secrets.

Proposed :

• The first user is "the generator"
• Store the public key of the generator in the repo
• Generate a symmetric key for encrypting the secret content in the repo
• Store an asymmetrically encrypted copy of this key using the public key of the generator
• In order to authorize additional developers
  • They commit their public key to the repo
  • The generator (or anyone else already enrolled) verifies their key in the appropriate manner
  • The generator (or anyone else already enrolled) can

jak enrol <identify their public key>

• This causes another copy of the symmetric key encrypted to their public key to be stored

This obviates the need to distribute a symmetric key via out-of-band, provides a clear list of which devs have access to the secrets, and provides for a means of rotating the secrets for e.g. excluding one of them from access

• Change secrets
• Remove offending dev from public key list
• Regenerate symmetric key and secret salts
• Re-encrypt secrets
• Re-encrypt symmetric key for remaining authorized users

[chrisdl]

First things first. Great idea!

Thank you for taking the time to write this all down. We were discussing this quite a bit when we were planning what jak should do and should not do. In the end we went with a very very simple key management strategy of "help people generate a secure key". We never did add any key sharing and management beyond that because we wanted jak to be very simple to use, and for this type of scheme to work a working knowledge of public key cryptography would need to exist across a team or at least in one "champion" that would help the others get setup.

A couple of considerations:

• if they can generate public/private keys, add the publics to a folder etc. then they can probably get the symmetric key shared securely anyway thought a side-channel. or even as a commited piece of information. Having the functionality in jak would only help a little bit.
• unenrolling someone is nice, but since it is in git anyone who was once enrolled would have access to the previous symmetric key, meaning you would need to rotate the symmetric key every time a public key is removed, and also rotate whatever secrets you are encrypting. TLDR: once given access revocation is not a very powerful action. Which is of course equally true of the symmetric key, im just saying that public key crypto doesn't meaningfully improve that situation.

With these things in mind, I think the feature you are talking about would be excellent. But I also don't really want it to be added to jaks core functionality since my main stated goal of jak is to be easy and secure. While this would make things more secure, it would make things a lot less easy. Ideally this would be an optional piece of functionality which brings me to the feature I've been meaning to add to jak: plugins. If jak could have a way to add plugins, this key sharing plugin would be an excellent first plugin. My original plan was to make the first plugin be an AWS KMS integration, for precisely the same usecase (sharing the key across the team in a secure manner).

Anyway, those are my high level thoughts on the matter. Is this something you would be interested working on? Is your team using jak and need this feature (I would love to know what you are using jak for)? Or is this more of a feature you hoped could be added and just thought you would fire off a request and see what would happen?

[awilkins]

Jak was in an article someone at work shared on Slack, I looked, and the notion of key exchange popped into head. Jak trades sharing multiple secrets through a back channel with a single secret, and is therefore still vulnerable to attacks on back channels.

Just emptying the idea out of my head rather than lose it, really. Think Jak is a nice idea, but my workplace is large enough we'll use something more "enterprisey" like Vault for secret storage.

[chrisdl]

Totally makes sense to use something more enterprisey at a bigger level. Jak is fine being a utility for smaller teams of developers to manage things they want encrypted in git repos. Thanks for the idea! I'll keep it in mind down the line.