[
https://issues.apache.org/jira/browse/DERBY-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291838#comment-13291838
]
Rick Hillegas commented on DERBY-5622:
--------------------------------------
Thanks for the repro and the additional analysis, Dag. Here are some more
observations:
1) When you create an encrypted database, you specify either an explicit
encryption key or a boot password. If you specify a boot password, then Derby
generates an encryption key for you. You can't go back and forth between these
techniques. Once you specify a boot password, you can't try to figure out the
generated encryption key and boot the database using the encryption key.
Similarly, if you create the database with an explicit encryption key, you
can't try to introduce a boot password later on.
This is because Derby stores different verification metadata for the two
techniques. The verification metadata is used to catch bad boot passwords and
encryption keys before actually trying to decrypt the conglomerates. If Derby
can catch a bad boot password or encryption key before trying to decrypt the
conglomerates, then Derby can raise an intelligible error message.
If the database was created with a boot password, then Derby expects to find an
encryptedBootPassword attribute in service.properties. The value of this
attribute includes a digest used at boot time to verify the boot password
before trying to decrypt the conglomerates.
In contrast, if the database was created with an explicit encryption key, then
Derby generates a verifyKey.dat file next to service.properties. The contents
of verifyKey.dat are used at boot time to verify the encryption key before
trying to decrypt the conglomerates.
If you try to switch your encryption technique later on, Derby will fail to
boot because it will not find the verification metadata needed by the other
technique.
2) If you change the boot password using boot attributes, this generates a new
encryption key and re-encrypts the data.
3) If you change the boot password using
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY, then a new encryption key is NOT
generated and the data is NOT re-encrypted.
4) Using SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY to change the boot password
strikes me as a little weird. The usage, however, goes back a long way, at
least as far back as Cloudscape 3.5. SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY was
originally designed to store Derby properties in the property conglomerate. The
boot password is not a property. It is a connection URL attribute. Furthermore,
the associated, generated encryption key is not stored in the properties
conglomerate. Instead, it is stored in service.properties. I don't think that
we should be manipulating the contents of service.properties with a procedure
which was designed to manage the property conglomerate. I support Knut's
suggestion on DERBY-4328 that we should introduce a new
SYSCS_UTIL.SYSCS_CHANGE_BOOT_PASSWORD procedure for changing the boot password
on the fly. I would support deprecating the use of
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY to change the boot password; we could
raise an error telling users to use SYSCS_UTIL.SYSCS_CHANGE_BOOT_PASSWORD
instead. To mitigate the backward compatibility problems, we could phase in
this change over the course of a couple releases, warning people in 10.10 that
the old usage will be deprecated in 10.11.
> Reduce the chance for hash collisions when checking bootPassword at boot time
> and when changing password.
> ---------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5622
> URL: https://issues.apache.org/jira/browse/DERBY-5622
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: Dag H. Wanvik
> Attachments: derby-5622-instrumentation.diff, repro.sh
>
>
> There are two issues, already seen in DERBY-2687:
> "the boot issue": there is a 1/2**16 chance that a wrong bootPassword will
> allow boot to proceed (but since its decoded key is wrong the boot will fail).
> "the password change" issue: similarly, there is a chance that the wrong
> bootPassword will be accepted trying to change it via
> SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('bootPassword', ...) at least for
> algorithms that do not check IV (initialization vector) in addition to the
> digest, e.g. "DES/ECB/NoPadding"
> The latter case may lead to data corruption, cf. DERBY-2687 discussion. I
> think the risk is fairly low, though: One would need to have execution
> permission to change the property if SQL authorization is used, and in most
> scenarios the supplied existing password would be correct. But since the
> results can be bad, it would be good to reduce or eliminate the risk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
