db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (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 Tue, 05 Jun 2012 17:14:23 GMT

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

Dag H. Wanvik commented on DERBY-5622:
--------------------------------------

Given an encrypted secret key S, which is stored in service.properties after having been encrypted
with the boot password BO, we have stored

      S' = encrypt(S, BO)

The payload data D exists encrypted using S:

    D' = encrypt(D, S)

so inverse, when we boot up again:

Using BO we do 

      S = decrypt(S', BO)

check digest(S) against stored digest, and get at the data:

      D = decrypt(D', S).

Now, when we try to change the boot password in the pathological case, we do this (using a
bogus old boot password):

   S-bogus = decrypt(S', B-bogus)

next, the check of S-bogus against digest and IV (initialization vector) would normally fail
it, but it could happen that it was erroneously accepted. The what happen is we store using
the new boot password (BN) onto service.properties:

        S-bogus' = encrypt(S-bogus, BN)

Meanwhile, the data is still encrypted with S; we don't reencrypt everything after changing
the boot password.

Next time we boot up again we do:

     S-bogus = decrypt(S-bogus', BN)

which works nicely and passes the digest since we use the correct new boot password, BN.

Now, trying to get the data:

     decrypt(D', S-bogus) 

will yield garbage, since we'd need to use S to get the correct data out.

So, to demonstrate this, I think you'll need to use a bogus key, make it pass the digest and
IV check using instrumentation of sorts, then shutdown, and reboot to see if your data makes
sense. They shouldn't.

                
> 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
>
> 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