About signatures for individual tokens

[cipriancraciun]

First of all I must make the distinction between MAC (checking that something hasn't tampered with the encrypted content) and "signatures" (checking the identity of the sender / encrypter). By my understanding of age, it doesn't support "signatures", it supports only MACs.

The readme mentions that the tool doesn't support MACs at the file level. I do assume that it does support MACs at the token (i.e. YAML value) level.

However, the issue with MACs, as implemented by age, is that they are useful only to detect if something non-malicious has happened in transit (or at rest), because anyone (without access to the private key) can replace an entire age encrypted file (YAML value in our case) with a completely different one, and nobody would observe it. (The MAC protects the original value from tampering by example swapping bytes, extending / truncating, etc. It doesn't protect against complete replacement.)

Why do I care about "signatures" for values? Because not having them allows an attacker (say a rogue employee that doesn't have the private key, but does have write access to the repository) to start replacing "sensitive" tokens with ones he controls, thus introducing security breaches.

For example, say one has an application that delivers sensitive information via email to people (or replace email with SMS, etc.). A rogue employee might want to have access to those emails, but he doesn't have access to the production instance or the sending infrastructure (say we are using a cloud provider to send those messages). Say that the credentials of the email cloud service are stored in a YAML file (read at production run-time) and protected by yage. Then, the rogue employee could create a different account (that he controls) on the same cloud provider, and swap the "real" credentials (say secret / access key) with his own. Thus he could convince the production server to route the client emails through a system he controls, thus allowing him to intercept the client messages.

(The same scenario can be applied to all kind of SaaS services, and to other internal resources / URLs / IPs that are used on critical paths.)

[glehmann]

The readme mentions that the tool doesn't support MACs at the file level. I do assume that it does support MACs at the token (i.e. YAML value) level.

yes

However, the issue with MACs, as implemented by age, is that they are useful only to detect if something non-malicious has happened in transit (or at rest), because anyone (without access to the private key) can replace an entire age encrypted file (YAML value in our case) with a completely different one, and nobody would observe it. (The MAC protects the original value from tampering by example swapping bytes, extending / truncating, etc. It doesn't protect against complete replacement.)

yes. With yage, we assume that the verification that nothing as been altered is done by the versioning system — most often, git.
We also trace the modification with the versioning system and we are able to see who made a specific change.

Why do I care about "signatures" for values? Because not having them allows an attacker (say a rogue employee that doesn't have the private key, but does have write access to the repository) to start replacing "sensitive" tokens with ones he controls, thus introducing security breaches.

For example, say one has an application that delivers sensitive information via email to people (or replace email with SMS, etc.). A rogue employee might want to have access to those emails, but he doesn't have access to the production instance or the sending infrastructure (say we are using a cloud provider to send those messages). Say that the credentials of the email cloud service are stored in a YAML file (read at production run-time) and protected by yage. Then, the rogue employee could create a different account (that he controls) on the same cloud provider, and swap the "real" credentials (say secret / access key) with his own. Thus he could convince the production server to route the client emails through a system he controls, thus allowing him to intercept the client messages.

(The same scenario can be applied to all kind of SaaS services, and to other internal resources / URLs / IPs that are used on critical paths.)

The exact same thing could be said with non encrypted code. A rogue employee can change the code to make the application do something to its own benefit

Other tools are subject to the same problem: SOPS is able to detect some partial changes with its MAC, but it won't see anything if someone encrypts a new file with the same keys. The new file will contain a valid MAC, but with tempered values.

Fortunately we have procedures to reduce this kind of risk — code reviews being one of them. The encrypted secrets could be treated in the exact same way.

[cipriancraciun]

Fortunately we have procedures to reduce this kind of risk — code reviews being one of them. The encrypted secrets could be treated in the exact same way.

I don't think code reviews apply to detect malicious secrets being sneaked-in:

• with proper code there is structure, logic, meaning; one can understand what is happening, thus code reviews do (hopefully?) help to detect malicious code;
• with "tokens" (be they encrypted or not), there is just pure random data; who can say if the randomly looking character string is the right one or not?

For example the rogue employee could be creating a commit where he adds a proper token, but also reorders some other tokens, and thus the diff shows more than the token he added. If the reviewer doesn't check that every other token has the old value, then the rogue employee could just switch the value to a new one and fool the code reviewer.

---

Anyway, I won't press more on this subject. It's your project, thus your prerogative. I was just trying to highlight some implications with the model you've chosen. :)

[glehmann]

yes that's indeed more difficult with encrypted values. Reviews is not the ultimate tool, but I can't think of anything that can actually help except that, and again I don't think the global MAC is helping much here.

That's a tough problem. If you have some ideas on what can be done, I'd be pleased to hear them

Thanks for your feedback!

[cipriancraciun]

Unfortunately as said MACs don't help with that, and age doesn't provide support for signatures.

Thus you have basically two options:

• sign (as in the cryptographic sense of "signing") each token with something else than age (perhaps using the same key pairs, but cryptographers don't usually advise reusing keys for both signing and encryption), and encrypt the result with age as you do right now; (I think this is somewhat "vulnerably-ish" in its own way?)
• do the above but in the reverse, encrypt and then sign; (I think this is perhaps safer?)
• use a cryptographic system that provides both privacy (i.e. encryption) and authentication;

Fortunately, for the later (having both encryption and authentication at the same time) X25519 (also used by age) does provide a solution: when encrypting it involves using two sets of keys, the private one of the "sender" and the public one of the "recipient"; thus it provides the following guarantee: only the recipient or sender can decrypt, and only the sender or recipient can encrypt; you do need the MAC to ensure you are not decrypting garbage. (In fact, age behind the scenes creates a ephemeral private/public key pair for each encrypted file, and puts the public key in the resulting payload, thus it seems that age works only with a single key pair, that of the recipient.)

---

What is the difference between "authentication" and "signing": in the above scheme that provides only "authentication" only the recipient can check (during decryption if the MAC verifies) that the sender is the expected one. With "signing" anyone can verify that something was encrypted by the sender, even if it can't decrypt the data.

---

In fact Filippo has a good blog about this topic, which pertains to age at the following link. (For me it took reading it a couple of times until I've grasped the fine details.)

• https://words.filippo.io/dispatches/age-authentication/

[cipriancraciun]

In addition to my initial comment (and the other thread above that focuses on authentication or signing) there is another factor that should be handled: binding an encrypted token to a particular key in your YAML.

Take for example the following context:

• we reuse the same example of an application that uses a SaaS service to send emails (or other messages), and a rogue employee wants to intercept client messages;
• our application has two environments, one staging, and one production, and thus two different instances of the SaaS service; for each environment we also have two YAML files;
• the rogue employee has access to the staging instance, but doesn't have access to the production one;
• the rogue employee now copies the settings from the staging YAML file and pastes in the production YAML then deploys;

Even if you implement signing and/or authentication, because we didn't also tie that signature / MAC to the "context" (i.e. "this is the encrypted SMTP SaaS secret key for the production instance"), one can transplant tokens from one place to another.

Thus, when you implement the signing / authentication I would also include as "additional data" (assuming you are using an AEAD algorithm) the following information:

• the path of the YAML file (as relative to the root of the repository), or at least the YAML file name;
• the path of the key in the YAML file; (i.e. our-service.smtp.secret-key)

---

The building blocks that age uses (i.e. X25519 and ChaCha20-Poly1305) already provide you with everything to implement both authentication (via X25519) and "YAML key binding" (via ChaCha20-Poly1305 "additional data"). I just don't think you can completely reuse the exact age implementation.

[glehmann]

You propose that someone that change an encrypted values also signs it, so I guess the signature must be verified during the deployment against a set of allowed identities that are actually allowed to change these values?

[cipriancraciun]

More-or-less yes, I think there should be a mechanism to sign / authenticate tokens, and then a mechanism to verify that a certain set of keys have done the signature / authentication.

I don't think it needs to be too complex, perhaps having a single key to sign / authenticate stuff would suffice. (That can be shared between trusted employees.)

However, please do pay attention to the "context" I was mentioning above (i.e. the "authenticated data" in AEAD encryption schemes) as that is as important as signatures / authentication.

[glehmann]

I like the idea, I have to think more about how to do it.
I'm not saying it will go in yage soon – my use case where we check who is authorized to push to the main git repository is already covered :-)