[
https://issues.apache.org/jira/browse/NIFI-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-2652:
--------------------------------
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.
was:
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.
> 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.1.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)
