Document that PGP encryption does not provide authentication

[NeilMadden]

Sops uses AES-GCM that is an authentication encryption mode, providing both confidentiality and integrity/authenticity of the encrypted configuration values. That is, nobody can read them and also nobody can alter them or generate a fake configuration file. AES-GCM is used with a random data encryption key (DEK) that is then itself encrypted with either KMS or PGP/GPG.

When used with KMS (at least in the default setting) this authentication property is preserved as the DEK is both encrypted and authenticated (and optionally signed) by the KMS. This ensures that only users that were authorised to access the KMS could have encrypted that DEK.

However, for PGP encryption the DEK is only encrypted and not signed or authenticated. This means that anybody with access to the PGP public key can generate a fresh DEK, use that to encrypt a new version of the config file, and then encrypt their DEK with the public PGP key. For example: while they may not be able to read your database server credentials, they can substitute them with their own server credentials, redirecting all your data to their database.

(NB: keeping the public key(s) secret is not really a good defence here as typically public key encryption systems do not make any claim to keep public keys secret).

This should be documented to make users aware that sops doesn't provide authentication of configuration files when used in this configuration, and so users should ensure authenticity of their configuration by other means: e.g. keeping their configuration in a git repository that requires signed commits from a known set of trusted keys, or using other access controls to restrict write access to the file(s).

A possible enhancement to sops itself would be to allow a signing private key when encrypting/editing a file with PGP, and to verify the signature against a configured set of public keys when decrypting it.

[nipil]

First of all, if this topic is already solved, and there is a workaround, please disregard my comment, and point me in the right direction.

Otherwise, please allow me to bump this, as i think this is an important issue. I actually only realized this after a few month of using SOPS with GPG.

Not being able to prevent anyone (with access to a file) to completely replacing all values with anything they want (as anyone can encrypt with the public key) is a real bummer, and an open door for any kind of possible redirection/honey/leak traps for the consuming systems.

From my newbie point of view, a simple "auto-sign & auto-verify if present" would be a good start. Let's say, with the private key (if available) associated with the selected public key used for encryption. That way, you would prevent outside parties to overwrite your files without you noticing.

[felixfontein]

I'm not sure this is an issue that SOPS itself can really solve. While we could add a signature of one of the GPG/Age keys who created / last edited the file for the encrypted DEK, this will not help you that much:

1. Because of backwards compatibility you can always encrypt the file with an older verison that didn't sign yet. (To work around that you need another check - outside SOPS - that makes sure that the signature is present.)

   Especially the "auto-verify if present" is problematic, as it would be easy to simply remove that signature from the encrypted file. That would only protect you from users who don't really know what they are doing, but not from "real" bad actors.

2. This will not help you if someone replaces an encrypted file by an older version of it (or a newer version that shouldn't be in use yet), as these are properly signed.

3. Regarding the suggestion from the OP:

   A possible enhancement to sops itself would be to allow a signing private key when encrypting/editing a file with PGP, and to verify the signature against a configured set of public keys when decrypting it.

   This can already be done easily with existing tools, such as GPG, without involving SOPS. Simply create scripts that help with encrypting / decrypting SOPS files (by signing and validating signatures), and use these instead of directly calling SOPS.

Also, generally, if someone can simply replace files in your repository or on your servers / in your services in bad faith without you noticing, you have very different (and way bigger) problems. But how / whether that's possible depends on your system design and that's not something SOPS can (or probably should) solve for you.

(And yes, I concur with the OP, this should be documented.)

[nipil]

These are very good points. I especially would not have thought about the "replace by an older valid file". Which defeats the protection in all 3 examples...

Regarding point 1 and 2, we could take into account that distributed version control systems would allow to detect alteration of history, as you would get a discrepency between the remote and local copies. But for any non-dVCS, or clone-from-scratch cases, the rogue rewrite would not be detected, so that is not a general solution.

Regarding point 3, i was thinking of SOPS being that "cryptography scripting tool", and wrapping another layer of cryptography around SOPS seemed counter-intuitive (or rather, inelegant/redundant), when the signing feature could be incorporated.

So yes, there does not seem to be a bulletproof solution (SOPS-based or otherwise) against rogue rewrites, except using something like an external revocation list (forward-moving only) as a complementary referee, where only the latest "good" version of a file could be accepted and used, and all previous versions be invalid by principle.

Thanks for your time and explanation, the subject is more complex than i would have naively thought.

[felixfontein]

Regarding point 3, i was thinking of SOPS being that "cryptography scripting tool", and wrapping another layer of cryptography around SOPS seemed counter-intuitive (or rather, inelegant/redundant), when the signing feature could be incorporated.

That is true, but: this adds another layer of complexity to SOPS, which only has limited benefit. SOPS already does quite a few things that it probably shouldn't and that make it more complex than necessary, and generally complexity is not good for security. So I don't see that something like this will get added anytime soon.

But: it doesn't hurt to discuss this and come up with new ideas. Maybe at some point someone figures out a good way how to incorporate something like this into SOPS that brings more benefits.