db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.
Date Fri, 08 Jun 2012 16:04:23 GMT

    [ 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

       

Mime
View raw message