Managing a shared set of secrets with a compromised identity

[mattpascoe]

I'm curious what folks are doing to share their secrets with friends/family or a small team?

Clearly you set up multiple recipients using their public identity.

Specifically I'm curious what people do to share the encrypted files. I would assume most people would say to use git. You commit your change and push it to a remote repository and share it that way.

What I'm specifically thinking through (and I have not yet seen documentation discuss this finer point) is the case where someones identity is compromised. Lets say my private identity file gets stolen (passphrase aside).

Great! I quickly go rotate my keys and push back to git. All is well everything is encrypted with all new identities that are no longer compromised. BUT if this was in a public git repo then now all they have to do is just check out an older commit and they can decrypt whatever was in there at that time.

So I'm guessing the only protection here is to NEVER commit your encrypted files to a public git repo! You should have at least another layer of credentials that protects the git repo as well so it is not public.

Basically, just because it is encrypted and you have rotated keys does not make it 'safe'. You must also ensure that the bad actor does not have access to any historical versions of the encrypted files. This can be difficult given certain situations. It can be managed but I never see this nuance discussed in any documentation. I feel like there might be a lot of folks thinking things are just great because its 'encrypted' and they may not realize the risk that exists in certain situations. I'm ultimately trying to design my workflow around sharing that mitigates these types of scenarios.

Thoughts?

[felixfontein]

So I'm guessing the only protection here is to NEVER commit your encrypted files to a public git repo! You should have at least another layer of credentials that protects the git repo as well so it is not public.

Yes, that's something I would definitely avoid (except maybe for things that aren't that important / sensitive; though I wouldn't do that either).

If you want to avoid git (like when sharing secrets with not that git-adept friends / family), you can also use other file sharing / synchronization tools, like Syncthing.

[mikeflame]

You're right. Rotating keys only protects the ciphertexts you write from now on; every value that was ever encrypted to the stolen key has to be treated as disclosed, so the real fix is changing the secret values at their source (DB passwords, API tokens). @felixfontein's advice (private repo, or Syncthing) limits who gets the history, but it can't undo a leak that already happened. The docs now have a section on the order of operations: Rotating secrets after a key in a key group has been compromised (added in getsops/docs#34).

Three things I'd add:

1. updatekeys keeps the old data key. It unwraps the existing data key and re-wraps the same key for the new recipient list (updatekeys.go#L101-L107). Only rotate creates a new data key and re-encrypts every value (rotate.go#L69-L79). I checked with sops 3.13.3 and age: after removing recipient B with updatekeys, the data key and every ENC[...] value stayed byte-identical. B could no longer open the new file directly, but when I then set a new password without rotate, B could read it by copying their sops.age entry from the old commit into the new file. So the order is:

# key already removed from .sops.yaml
sops updatekeys -y secret.sops.yaml
sops rotate -i secret.sops.yaml
git commit -am "remove compromised key" && git push
# only now change the real passwords/tokens

2. The recipient type decides whether old commits stay readable. With age or PGP, the private key unwraps the data key locally (age/keysource.go#L243-L258), so a stolen key reads every old commit offline, forever. With a KMS recipient, the file only holds the KMS-wrapped data key in sops.kms[].enc, and every decrypt is a live kms:Decrypt call (kms/keysource.go#L319-L342). The same applies to GCP KMS, Azure Key Vault and Vault transit. At work we use SOPS with AWS KMS, and this is the property that matters: revoke the principal (key policy/IAM, deactivate the access key, or revoke active role sessions) and the old commits are cut off too. CloudTrail logs every successful Decrypt (and access-denied attempts); Event history keeps 90 days of them even without a trail. Two caveats:

• A data key they already unwrapped stays theirs. CloudTrail shows whether that happened.
• An offline age/PGP "backup" recipient in the same key group brings the offline problem back.

If you want per-person age keys without offline access to history, put KMS in a second key group with shamir_threshold: 2. Everyone then needs their age key and KMS access, so one stolen age key alone can't decrypt any commit (key groups).

3. Set things up so removing someone is surgical:

creation_rules:
  - path_regex: ^prod/
    shamir_threshold: 2
    key_groups:
      - age: [age1alice..., age1bob...]   # one recipient per person
      - kms:
          - arn: arn:aws:kms:eu-west-1:111122223333:key/...
            context: {env: prod}          # shows up in CloudTrail Decrypt entries
  - path_regex: ^dev/
    age: [age1alice..., age1bob..., age1carol...]

Use one file (or directory) per environment so a leak stays scoped, keep the repo private, and use short-lived credentials plus MFA for KMS access.

Incident checklist

1. Revoke what you can: the person's KMS access, their access keys, active role sessions.
2. Remove the key from .sops.yaml, then run sops updatekeys -y and sops rotate -i on every file that key could read. Commit.
3. Rotate every value those files have ever held, at the source. That includes values that were deleted from the file but are still in history.
4. KMS: aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<stolen key id> lists every call made with those credentials in that region, including each KMS Decrypt; with context set you also see which environment was read.
5. Don't count on rewriting git history. Anyone who cloned already has it.

[Dexmachi]

Also, I personally really recommend using some type of secret/password manager to fetch and use decryption keys. Sops doesn't fully support stream-based token reading tho.

But having like a 3/3 quorum, where the local, the provided and the KMS keys are required does improve security a tad

[mikeflame]

Agreed on the password manager. SOPS can already do that without the key touching disk: since 3.10.0 it runs SOPS_AGE_KEY_CMD and reads the age identity from its output (SOPS_AGE_SSH_PRIVATE_KEY_CMD does the same for SSH keys), e.g. export SOPS_AGE_KEY_CMD='op read "op://Private/sops-age/key"'. And the 3-of-3 quorum is three key groups with shamir_threshold: 3. The trade-off is that losing any one of them locks you out, so keep a recovery path for the KMS group.

[Dexmachi]

yeah, but that's only for age tho

I meant that for smth like a openbao token, this gives you a causal audit trail (you need to get the key from op before you can connect to, say, openbao)