The Problem

A developer creates a database (and usually an accompanying client application) for installation on servers at remote sites. At such sites it is usual for a person at that site to have full access to the computer on which the Firebird server is running – in order to be able to perform backups and other maintenance tasks. As described in the background information, direct access to the database file provides the ability to gain full and unrestricted access to all the information in the database – both data and metadata.

In such cases the developer may not trust the users at these remote sites to keep the intellectual property represented by the database confidential. The fear may be that the users will reverse-engineer the database for their own purposes, or that these remote sites will fail to maintain the security necessary to prevent unauthorised access to the database.

This leads to the common questions on the Firebird lists along the lines of:

“I want to—”: “—protect my database design (table structures, stored procedures, triggers etc.) from all users of the database at a remote installation. How can I do this with Firebird?”
“I want to—”: “—stop any users at a remote installation from accessing these particular tables of data. They contain proprietary information used internally by the application.”

Firebird (at least to v1.5) provides no built-in encryption facilities. The simple answer to both of these questions is that it cannot be done using the current capabilities of Firebird. A user who can get direct access to the file gains access to all details within that file.

In the first instance no workaround is feasible because the server itself must be able to read the metadata. In the second instance it may be possible to implement client side encryption/decryption features, but then you will lose the ability to make effective use of database indexes and search facilities – and key management remains a major problem (more below).