| Firebird Documentation Index → File and Metadata Security → The Solution |
|
|
|
There is really only one possible solution to these requests: Host the database and server at your own site and let the clients connect to your server remotely, through dial-up or Internet facilities etc. Terminal server (Windows or Linux/Unix) capabilities could be a useful way to implement such requirements.
In this way you maintain control over the database file and can restrict access to the various features and structures of your database using the usual Firebird internal security features (roles and privileges, etc.).
It is worth pointing out that there are difficulties even in this situation, if your intention is to protect the structure of your database.
Various database development libraries interrogate metadata, such as primary key, domain and similar structural information, in order to make development of client applications easier. Consequently, you may discover that you cannot prevent users from accessing metadata without also preventing your application from gathering the information that it requires.
This may mean that you will need to choose between allowing metadata details to escape from your server via a sophisticated data access interface and spending the considerable extra time it takes to develop an application using a less sophisticated access library.
There is also the issue that most client applications inherently “leak” structural information about the database with which they interact. It is very rare for a database-centric application to have an interface that does not reveal many details about the table structures that it uses.
Some details may be hidden behind views and selectable stored procedures, but defining such features purely to try and hide structural information is an exercise in frustration. It is probably futile, anyway, since some details will escape, whatever you try.
Before continuing with other discussions relating to encryption of Firebird data, I do want to highlight that it is possible for users to protect their databases with encryption. This does not help developers who want to hide information from legitimate users, but it may help to meet the requirements of customers wanting to increase the security of their databases.
In some office situations it may not be practicable to locate the Firebird server computer in a truly secure environment. During times when the office is attended the likelihood that anyone will be able to access the computer to copy the database files (or steal the computer or hard disk to get the files later) may be quite low. However out of normal working hours (nights and weekends) it may be a different matter. Someone could gain access to the office, take the hard disk out of your computer (or take the entire computer) and take it away to access the database.
While Firebird itself provides no built-in encryption features there are some excellent products that do. You could install software that creates an encrypted volume on your computer and locate the database file (and any other confidential data) on that volume. When the computer is shut down all data exists in an encrypted file and cannot be accessed without the key. When you start the computer you have to mount the encrypted volume and supply the secret key before the data can be accessed. This additional, and necessarily manual, step in the start up process may be inconvenient but it can provide excellent security for unattended computer systems.
Software with these capabilities includes: TrueCrypt (www.truecrypt.org), Bestcrypt from Jetico (www.jetico.com) and PGPDisk (www.pgpi.org/products/pgpdisk/ – note that this link goes to an old freeware version, that site has links to newer commercial versions of the product). There are others but the last two are ones that I have used myself.
Because of the needs described above it is common for users to request that Firebird should, in a future version, add the ability to encrypt metadata, selected user data, or even the entire database. Not being a Firebird core developer, I cannot say categorically that it will not happen. However, the issue is not really whether encryption is practicable or useful, but a matter of whether key management would provide a solution to the problems we are examining.
Encryption can only be as good as the secret key required for decryption. It can be worse but it cannot be better. There are several excellent encryption algorithms available that could be used. When good encryption is used, attacks are likely to be against the key rather than against the encryption itself.
So let's look at how things would work if Firebird were to encrypt the metadata in a database...
Before the database could be accessed the secret key would need to be supplied. Giving the decryption key to the user would be pointless, simply bringing us back to the original problem. So, presumably, whenever the customer restarts the server they would call the developer who would then dial in and enter the needed key. Even if this were practicable, it is not necessarily going to solve the problem. For example; the customer could install some monitoring software on their server to detect the key as it is entered.
There are hardware based solutions to provide a key to a decryption process. But again this would need to be in possession of the client, and if we don't trust the client we cant stop them from using it to gain access to the database from another server where the SYSDBA password is known.
Firebird is an open source product. If the encryption facilities were built in, or open source plug-in libraries were used, it would be feasible for users to build their own versions of the server or plug-in that not only performed the necessary encryption and decryption to access the protected database but also output the key, or simply output the decrypted details directly. The developer, not being in control of the server, can neither detect nor prevent such activity.
You might consider building your own version of the Firebird server with the decryption key hidden in the executable. However, decompilers are available. It would not take long to discover the key simply by comparing the decompiled versions of your custom Firebird build with the normal, unencrypted version.
Various database products do exist which purport to provide strong encryption. Perhaps the encryption is strong but, unless the key management is in place to support this feature, the encryption is not going to achieve the desired effect. It may encourage you to believe you are protected, but you need to study the key management to discover if this is really true.
The painful truth is that, once you lose control of the hardware on which the encryption and decryption takes place, all bets are off. If the decryption key cannot be kept reliably secure then even good encryption becomes little more than security by obscurity.
Some people request encryption of the database data so that they can try and limit the dissemination of data. They are happy for the particular authorised user to see the data, but they wish to limit that user's ability to distribute the data to other people.
Just imagine for a moment that all the key management problems described above have been solved, so that it has become impractical for the user to just copy the database. In such cases the user would simply write a small program that extracted the data they were interested in (from the legitimately installed server) and copied that data to its own file or database.
I guess it is possible that Firebird might provide some form of application authentication system in the future that may make it possible to limit this form of data extraction, however most of the same problems exist. If you do not control the server you cannot prevent the user from installing a version of the server that does not require the authentication.
At various times people have suggested that removing SYSDBA access to a database could be the solution. The idea behind it is that, when the database is moved to a new server where the SYSDBA password is known, it will not help the person because SYSDBA does not have access anyway. Some have reported limited success in this respect by creating an SQL role name of SYSDBA and making sure it does not have access to the database objects.
However it does not really solve the problem. The database file can be viewed with a hex viewer or similar utility and the list of available user names discovered. (Discovering the owners of the database objects would be particularly useful.) Once known, these names can be added to the new server and used directly.
An even simpler workaround might be to use the embedded version of Firebird server (see below) or to compile your own version of the Firebird server that ignores security constraints.
There has been some suggestion about allowing the SYSDBA user name to be changed. This may offer some limited protection against brute-force network attacks against the SYSDBA password, since such attacks would need to guess both the user name and its password, but it does not help protect the system from a person with direct access to the database file.
When you write and define a stored procedure or trigger for a Firebird database, the server stores an almost complete copy of the procedure source code along with a “compiled” copy referred to as BLR (Binary Language Representation). It is the BLR that is executed by the server, the source code is not used.
Some developers attempt to protect at least some of their database metadata by deleting the source code from the database before distributing the database (a simple direct update against the relevant metadata table fields). I recommend that you don't do this for two reasons...
BLR is a fairly simplistic encoding of the source code. It would not be difficult to decode the BLR back to a human readable form. Such a decoding would be without comments and formatting, but the SQL that goes into a stored procedure or trigger is rarely so complicated that this would cause much of a problem. Hence the protection offered by the removal of source code is not very significant.
The source code can be useful for other purposes. It allows fixes to be applied directly to the database without needing to bring in the full source from elsewhere (and then remembering to remove it again when the fix is applied). The source code is also used by various utilities, such as my own DBak application – an alternative backup program to “gbak”. I have not bothered to write my own BLR decoder at this stage, so DBak relies on the availability of the source code in order to be able to build a DDL script to reconstruct a database.
|
| Firebird Documentation Index → File and Metadata Security → The Solution |