Restarting ADS Service corrupts AES256-encrypted data dictionary (Error 7068)

[Former Member]

Evaluating the OpenSSL encryption dlls we have come across a serious issues after converting a non-encrypted .add files to AES256, the data dictionary becomes corrupted (error 7068) when trying to open it again after restarting the ADS Server/Service.

Server and Client versions of Advantage Database Server are both 11.1.0.24.

The encryption dlls are version 0.9.8zg (provided by Chris Franz in order to evaluate them).

ADS Server is 64bit (with the corresponding win64 dlls copied to the ads installation folder) and the Client is 32bit (with corresponding win32 dlls copied to Windows\System32 and Windows\SysWow64).

Steps to reproduce problem:

In the Advantage Data Architect (ARC):

a) Create an Advantage Dictionary File with .adt tables

b) Close the newly created .add connection and open the ADTDemoData data dictionary

c) Open the SQL utility and run:

EXECUTE PROCEDURE sp_SetDDEncryptionType( 'C:\somepath\test.add', 'x', 'y', 'AES256', TRUE );

(x being the actual .add pwd; y the actual DDpwd)

d) Close the connection; open the newly updated aes256 .add to confirm it opens fine

e) Shut down the Advantage Configuration Utility; then restart it again

f) Open ARC, and attempt to open the aes256-encrypted .add; ARC says:

Error 7068:  The requested database operation is not allowed unless encryption was enabled.  axServerConnect

At this point, the AES256-encrypted .add is toast.

[HakanHaslaman]

Did you already check this KBA

[Former Member]

Hakan:

Thanks for replying.  I looked at the KBA you pointed to, but I'm not using local server.

Our setup is ADS Remote Server v. 11.10.0.24 (same version for the client dlls), so I would think the fix to that bug would already be included in v11.x.

I actually reduced the problem to ARC alone just to make sure the issue wasn't in our code

(we use the ADS API with the Harbour compiler) and while the .add is just RC4 we don't have any

corruption issues; things go south as soon as we update the encryption to AES256.

Setting the password in a clear text file isn't really an option we can consider.  I wonder if there are newer SAP-built openssl dlls that would take care of the problem while sticking with ADS v 11.1 as we can't really update to v12 right now as we first need to make sure we can full convert our current

apps that used .dbf files into a full-fledged dataabase with .adt tables and .add encrypted files.

Thanks.

[Former Member]

Hakan:

New development.  I must have misinterpreted the ACE API docs regarding what parameters are only to be used in adsDDCreate101() and adsConnect101().   I was only providing DDPassword= to the former, but not the latter (in the cases where the add was strongly encrypted up front; other cases involved calling the stored procedure sp_SetDDEncryptionType()).

Since we might have some installation that will not use strong encryption and others than will (we're still in alpha testing) I'm passing DDPassword= regardless and I see it doesn't affect non-encrypted .add's (other than a 7168 that gets logged in ads_err.adt that seems not to affect adsConnect101()).

With that in place, I was now able to repeat the test I mentioned in my original post, and stopping and restarting the ADS service doesn't corrupt the data dictionary anymore.

So one concern creeps up:  when we have our support techs troubleshooting clients, using ARC with no SE_PASSWORD= setting in place will still risk damaging the database a distinct possibility.

Having the SE_PASSWORD= visible kind of defeats the purpose of keeping the database from prying eyes.

Wondering if there's a better way of not exposing the table encryption password in clear text and have ARC ask for it, just like it does for the .add password itself.

Thanks.