Re: Storing encryptionAlgorithm in service.properties (DERBY-42, DERBY-46, DERBY-4493)

[Francois Orsini <fr...@gmail.com>]

Hi Brian,

As you have noticed, there are 2 database key storage modes:

- Database Key store:
  - encryption key generated by Derby and stored in service.properties

- External Key store:
  - encryption key is provided (externally) by the application.

Your C) scenario sounds like a bug to me. You should be able to specify a
different database encryption algorithm than the default Derby one, even
when passing an external encryption key.

The rational behind not storing the encryption algorithm in
service.properties in case of an external key being provided, might have
been for extra added security. In this case, Derby should not only rely on
its default encryption algorithm but *also* allow the passed-in *
encryptionAlgorithm* to be used (c.f. Bug above).

If you look at the reference manual and the *encryptionKey* attribute, it
says:
http://db.apache.org/derby/docs/dev/ref/ref-single.html#rrefattribencryptkey

"When booting an existing encrypted database, you *must* also specify the
encryptionAlgorithm attribute if the algorithm that was used when the
database was created is not the default algorithm."

The documentation *even* shows an example of passing the encryptionAlgorithm
attribute along with the *encryptionKey* one.

jdbc:derby:newDB;create=true;dataEncryption=true;
   encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768

So yes, this does sound like there is a bug per your C) scenario.

Unfortunately, the documentation about 'encryptionAlgorithm' is also
confusing, as it reads:
http://db.apache.org/derby/docs/dev/ref/ref-single.html#rrefattrib60346

"The encryptionAlgorithm attribute must be combined with the
bootPassword=key<http://db.apache.org/derby/docs/dev/ref/ref-single.html#rrefattrib42100>attribute
and the
dataEncryption=true<http://db.apache.org/derby/docs/dev/ref/ref-single.html#rrefattrib15290>attribute.
You have the option of also specifying the
encryptionProvider=providerName<http://db.apache.org/derby/docs/dev/ref/ref-single.html#rrefattrib88843>attribute
to specify the encryption provider of the algorithm."

No mention about the fact that encryptionAlgorithm can also be combined with
the *encryptionKey* attribute.

> 1: if the presence/absence of encryptionAlgorithm in service.properties
> is intentional or accidental.

I would say intentional but of course this should be verify-able by looking
at the code more closely.

> 2: if the system intentionally ignores encryptionAlgorithm in the
> connection URL when it is already present in service.properties, or
> whether it is an accident

It does seem intentional to me, since the system would assume that the
database was created with the
stored encryption algorithm in service.properties (otherwise it would be an
issue with consistency and
metadata about how a database was encrypted.

> 3: how best to document the requirements for providing encryptionAlgorithm
> at connection time.

This definitely needs to be improved / fixed based on your experiments and
findings.

I know this is not much help but I wanted to throw a bit more comments to
the pot ;-)
and if I find more info I will post.

--Francois

On Sat, Dec 26, 2009 at 11:38 AM, Bryan Pendleton <bpendleton@amberpoint.com
> wrote:

> I'm confused about when the encryptionAlgorithm value is stored
> in service.properties, and when it is not.
>
> I did some simple experimentation, and it seems that:
>  - if I encrypt a database using bootPassword, the value IS
>   stored in service.properties
>  - if I encrypt a database using encryptionKey, the value is NOT
>   stored in service.properties
>
> It also seems that if the value is stored in service.properties,
> then I don't have to provide it as an attribute when connecting,
> but if the value is not stored in service.properties, then I do
> have to provide it as an attribute when connecting.
>
> Furthermore, if the value IS stored in service.properties, and
> then I provide a different value for encryptionAlgorithm when
> connecting, the database uses the value from service.properties,
> NOT the value from the connection URL attributes, which is
> confusing (see DERBY-4493).
>
> Further-further-more, it appears that I can add or remove the
> value of encryptionAlgorithm to service.properties after the fact.
>
> Here are a few scenarios, with some notes:
> a) create with
>
>   jdbc:derby:encDB;create=true;dataEncryption=true;
>   encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768
>
>   - encryptionAlgorithm is NOT stored in service.properties
>   - connect with jdbc:derby:encDB;encryptionKey=6162636465666768
>     works because encryptionAlgorithm is the default algorithm
>   - connect with
> jdbc:derby:encDB;encryptionAlgorithm=Blowfish/CBC/NoPadding;
>     encryptionKey=6162636465666768 fails because the algorithm is a
>     mismatch, but the error message says "the given encryption key
>     does not match the encryption key used when creating the database"
>
> b) create with
>
>   jdbc:derby:testdb;create=true;dataEncryption=true;
>   encryptionAlgorithm=Blowfish/ECB/NoPadding;bootPassword=$ecureC@deCanBr
> @kE0074242
>
>   - encryptionAlgorithm IS stored in service.properties
>   - connect with jdbc:derby:testdb;bootPassword=$ecureC@deCanBr@kE0074242
>     works, because encryption algorithm need not be provided.
>   - connect with jdbc:derby:testdb;encryptionAlgorithm=DES/CBC/NoPadding;
>     bootPassword=$ecureC@deCanBr@kE0074242 works, which seems wrong,
>     because it is actually using a *different* encryption algorithm than
>     the one which was specified in the URL attribute.
>
> c) create with
>
>   jdbc:derby:encDB;create=true;dataEncryption=true;
>   encryptionAlgorithm=Blowfish/ECB/NoPadding;
>   encryptionKey=c566bab9ee8b62a5ddb4d9229224c678
>
>   - encryptionAlgorithm is NOT stored in service.properties
>   - connect with
> jdbc:derby:encDB;encryptionKey=c566bab9ee8b62a5ddb4d9229224c678
>     fails, because encryptionAlgorithm is not the default, and was not
> provided.
>   - manually edit service.properties to contain
>     encryptionAlgorithm=Blowfish/ECB/NoPadding
>   - now connect with
> jdbc:derby:encDB;encryptionKey=c566bab9ee8b62a5ddb4d9229224c678
>     works fine.
>
> d) If I create with a non-default algorithm, using bootPassword, then:
>
>   - encryptionAlgorithm is stored in service.properties
>   - can connect using just bootPassword on connection URL
>   - if I manually edit service.properties and REMOVE the
> encryptionAlgorithm,
>     then I now have to provide the encryptionAlgorithm when connecting.
>
> I'm trying to figure out:
> 1: if the presence/absence of encryptionAlgorithm in service.properties
>   is intentional or accidental.
> 2: if the system intentionally ignores encryptionAlgorithm in the
>   connection URL when it is already present in service.properties, or
>   whether it is an accident
> 3: how best to document the requirements for providing encryptionAlgorithm
>   at connection time.
>
> I see in http://db.apache.org/derby/binaries/djd_derby_security.pdf
> that Dan wrote:
>
>  With external key storage no encryption information should appear in file.
>
> But I'm not sure of the reasoning behind that behavior.
>
> I think that the documentation should read:
>
>   If you are using a non-default encryptionAlgorithm, and if the
> encryptionAlgorithm
>   value is not specified as a database property in the service.properties
> file,
>   then the proper encryptionAlgorithm value must be specified as an
> attribute
>   on the connection URL when connecting to the database.
>
> I also think that the system should check if encryptionAlgorithm was
> provided
> in BOTH the connection URL and the service.properties, and complain if they
> don't match.
>
> Thanks in advance for any comments or observations.
>
> bryan
>
>