Andy LoPresto updated NIFI-2652:
    Fix Version/s: 1.2.0

> Handle multiple invocations of the encrypt-config tool
> ------------------------------------------------------
>                 Key: NIFI-2652
>                 URL: https://issues.apache.org/jira/browse/NIFI-2652
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Configuration, Tools and Build
>    Affects Versions: 1.0.0
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>              Labels: bootstrap, config, encryption, security
>             Fix For: 1.2.0
> 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. 

This message was sent by Atlassian JIRA

Reply via email to