Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.0.0
Description
A discussion between jtstorck and myself led to some possible scenarios with the encrypt-config tool. If a user invokes the tool multiple times on the same input files (updating in place), what should happen?
Currently:
The tool will not operate on any already-protected properties. So sensitive properties present and unprotected would be protected by the first invocation. If, before the second invocation, new sensitive values were provided in the nifi.properties file, they would be protected by the second invocation. If the user provides the same key/password as the first invocation, all properties would be encrypted with the same key. However, if a different key/password were used, the properties encrypted on the second invocation would be protected with a different key, and the new key would overwrite the key in the bootstrap.conf file, rendering the first set of properties unrecoverable.
Possible solutions:
On invocation of the tool, it first tries to read the existing key from bootstrap.conf. If no key is present, operate as normal.
- Possibly require second entry of the key/password for confirmation to ensure it was not mistyped
If a key is present (one of the following):
- (Derive if necessary and) validate the key against the existing key and if it does not match, fail to run
- Decrypt any existing encrypted properties with the persisted key and re-encrypt all sensitive properties with the new key
The second option does not require the same key/password to be used repeatedly and also provides a mechanism for key migration/rollover.
Another possible error scenario is if the first invocation was run with the JCE unlimited strength cryptographic jurisdiction policies not present (so the system was limited to 128-bit encryption) and subsequent invocations are run with the policies installed (in which case the tool will attempt to use 256-bit encryption). The individual properties will be marked with key strength available at the time they were encrypted, so this would also indicate the second option above is more robust. However, if the opposite flow occurs (256-bit available at first invocation, 128-bit subsequently), the tool will not be able to decrypt and re-encrypt the existing protected properties.
