Database security

You have the option to encrypt or obfuscate your databases. Encryption provides secure representation of the data in the database whereas obfuscation only prevents casual observation of the contents of the database.

By default, databases are not encrypted or obfuscated. Text and binary columns can be read when using a viewing tool such as a hex editor. Consider the following options if you do not want your data stored as plain text:

Obfuscation This option provides protection against casual attempts to access data in the database but does not provide as much security as strong encryption. Obfuscation has a minimal performance impact. You do not need any special configuration to use simple obfuscation on your device.
AES 256-bit encryption This option encrypts databases with an AES 256-bit algorithm. Strong encryption provides security against skilled and determined attempts to gain access to the data but has a significant performance impact. You do not need any special configuration to use AES encryption on your device.
AES 256-bit FIPS 140-2 certified encryption (Windows and Windows Mobile only) Encryption libraries certified with the FIPS 140-2 US and Canadian government standard (using a Certicom certified cryptographic module) are provided. AES FIPS-certified encryption requires that you configure your device appropriately.

Remarque

Un composant sous licence distincte est requis.

Le cryptage certifié FIPS exige une licence distincte. Toutes les technologies de cryptage fort sont soumises à des réglementations d'exportation.

Voir Separately licensed components.

Consider the effects of database cache size when choosing to encrypt or obfuscate databases. There is an overhead increase between 5-10%, which can result in decreased performance. The exact effect on performance depends on the size of your cache. If your cache is too small, encryption can add significant overhead. However, if your cache is sufficiently large, you may not see any difference at all. For more information about cache sizes, see Cache size adjustment for an UltraLite database.

Database obfuscation

Database encryption

Encryption keys should contain a combination of characters, numbers, and special symbols to be effective. Long encryption keys reduce the chances of someone guessing the key.

Note

After the database is encrypted, the encryption key cannot be recovered.

Using Sybase Central wizards, you can specify UltraLite database encryption options during creation by clicking the Encrypt the Database option and then clicking Use Strong Encryption and AES.

Using the ulinit utility, you can specify the encryption key with the DBKEY parameter. Use the FIPS creation parameter to specify whether to use FIPS-certified encryption.

UltraLite API encryption options are available when creating a database. For UltraLite Java edition databases, specify the database key using the enableAesDBEncryption and setEncryptionKey methods instead of the DBKEY parameter.

Caution

You can change the encryption key after the database has been created but only under extreme caution.

This operation is costly and is non-recoverable. You can lose your database entirely if your operation terminates mid-course.

For strongly encrypted databases, store a copy of the key in a safe location. If you lose the encryption key, there is no way to access the data—even with the assistance of Technical Support. The database must be discarded and you must create a new database.

For more information, see:

The DBKEY parameter must be supplied when connecting to the database; otherwise, the connections fail. Encryption keys should be treated as sensitive information.