...
An initial key is generated by the installer in a special kind of Java keystore file called a "JCEKS" keystore, which stores secret keys instead of public/private keys and certificates. A parallel file also tracks the key version number. A tool is provided to regularly update this secret key (and increase the version), which can be pushed to cluster nodes and continually maintain the secrecy of this key. This should be done at least daily to limit the chance for, and damage from, exposure. You can list the keys with the Java keytool utility (change the <secret> accordingly):
| Code Block | ||
|---|---|---|
| ||
keytool -v -list -keystore sealer.jks -storepass <secret> -storetype JCEKS |
Each time the seckeygen utility runs, it generates a new iteration of the key and updates the key version number (and a date/time in a comment). It also maintains a limited number of earlier keys (defaulting to 30, set with the --count option), which should be set based on how often you run the script and how long earlier data used by clients needs to be readable. Any data written with the DataSealer is always encrypted with the latest version of the key, but any data encrypted with an older key can still be read as long as the key remains accessible.
...