Add Support For Encrypted Private Keys

[ajh-]

Problem:
When attempting to generate an attestation with an encrypted private key, witness throws an error stating it failed to open the key file. When using an unencrypted private key, witness works as intended.

Recommendation:
Add a password option/flag to prompt for user input or include within command. This would be like the -P, --password option included with in-toto-run or the -p, --prompt option with in-toto-sign.

I could also be overlooking this functionality within witness so please let me know if this is already possible.

[ChaosInTheCRD]

Hi @ajh-, thanks for submitting this issue!

This is certainly something that we need to fix with a degree of priority, as keys with passwords is a use case that we should support.

The only thing I am questioning at the moment is whether we should:
a) provide this as a flag, as you suggested. I think that this is likely the most flexible / secure method, especially when considering use in pipelines (you could mount the secret as a file, which is more secure than env var, or just use the env var with the flag.
b) provide an environment variable. The reason why I am suggesting this is in favour of reducing the amount of flags that we are presenting to users.
c) prompt the user to enter it into stdin. This is nice when using the tool on a client, but wouldn't be sufficient alone as it is limited when used in pipelines.
d) of course we could just implement all of these, but I think we should be cautious of expanding the amount of inputs we present to the user.

I would like to know your thoughts @ajh-, please let me know if this prompts any thoughts of how good / bad the user experience would be for each option.

[adityasaky]

This is another one that I think we might want to solve via go-securesystemslib (it's also something that comes up in gittuf for example: gittuf/gittuf#276). IIRC python-securesystemslib supports encrypted keys, though we should double check with the new signer interface. I wonder if we can look at that to see what the options are for submitting the passphrase for consistency + security.

[ajh-]

Hi @ajh-, thanks for submitting this issue!

This is certainly something that we need to fix with a degree of priority, as keys with passwords is a use case that we should support.

The only thing I am questioning at the moment is whether we should: a) provide this as a flag, as you suggested. I think that this is likely the most flexible / secure method, especially when considering use in pipelines (you could mount the secret as a file, which is more secure than env var, or just use the env var with the flag. b) provide an environment variable. The reason why I am suggesting this is in favour of reducing the amount of flags that we are presenting to users. c) prompt the user to enter it into stdin. This is nice when using the tool on a client, but wouldn't be sufficient alone as it is limited when used in pipelines. d) of course we could just implement all of these, but I think we should be cautious of expanding the amount of inputs we present to the user.

I would like to know your thoughts @ajh-, please let me know if this prompts any thoughts of how good / bad the user experience would be for each option.

@ChaosInTheCRD I think prioritizing a solution for option A (adding a flag) is sufficient (at least initially). From a user experience perspective, flags provide a level of explicitness that can sometimes be lost when defining just an environment variable behind the scenes. Using a new flag to reference a file or an environment variable seems like a good compromise.

[lukpueh]

IIRC python-securesystemslib supports encrypted keys

We actually just removed support for encrypted file-based keys from the relevant API for the following reasons:

• Given the supported signing mechanisms in securesystemslib, we consider file-based keys an edge case, which is mostly interesting for demos etc.
• Even without that the intended usage pattern for loading a signer, e.g. from a private key file, is non-interactive. This means a secret to decrypt the key file would need to be provided e.g. via environment variable, which in turn does not seem more secure than storing the unencrypted key content as environment variable right away.
• And lastly, in an interactive scenario, the code for loading and decrypting the private key material, and creating the signer can easily be provided by the application. This is what in-toto-run does when called --password as mentioned above.