[jira] [Commented] (NIFI-2652) Handle multiple invocations of the encrypt-config tool

["Yolanda M. Davis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15610070#comment-15610070 ] 

Yolanda M. Davis commented on NIFI-2652:
----------------------------------------

[~alopresto] I recommend allowing users to provide the old password  and new password in order to generate and port from old to new key. I figure this may be easier for users than needing to refer to hex master keys.

> 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
(v6.3.4#6332)