Request for Addition of On-Disk Full Database File Encryption Feature in Firebird SQL

111 views
Skip to first unread message

hassanein issa

unread,
May 4, 2024, 6:44:25 AM5/4/24
to firebird-support

Dear Firebird SQL Developers,

I am writing on behalf of several Iraqi Firebird users who are the providers of healthcare programs and databases. We are in urgent need of a comprehensive on disk all database file encryption feature in Firebird SQL to meet the new legal requirements for data security in the healthcare industry in Iraq. Failure to provide this feature would sadly force us to discontinue our use of the Firebird database, which we currently find fantastic, and reluctantly switch to alternative solutions that offer free or low-cost encryption out-of-the-box (such as SQLite or MS Access).

The current version of Firebird SQL does not offer a robust file encryption feature; it only provides column-level encryption, which is insufficient for our needs. Our customer are having a few concurrent connections ( from 2 to 10 as the upper limit and on the same local network ). Additionally, existing third-party solutions are prohibitively expensive for our small to medium-sized healthcare agencies. By incorporating an efficient and fast On-Disk full file encryption feature (like that in SQLite3 or Interbase for example), Firebird SQL would surpass other database solutions and greatly benefit organizations like ours.

We kindly request your consideration and collaboration in promptly adding this crucial feature. It is a mandatory requirement by law, and its implementation would not only enable us to comply with legal obligations but also enhance data security and privacy for all Firebird SQL users.

Should you require any further information or wish to discuss this matter, please do not hesitate to contact me at conh...@gmail.com, We sincerely appreciate your attention to this urgent issue and eagerly await your positive response.

Sincerely,

Hassanain Eesa
Email: conh...@gmail.com

Mark Rotteveel

unread,
May 4, 2024, 6:48:10 AM5/4/24
to firebird...@googlegroups.com
Such a feature already exists since Firebird 3.0[1], but does require
you source (e.g. buy) a third-party plugin that does the actual encryption.

As an aside, Firebird doesn't have column-level encryption.

Mark

[1]:
https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rlsnotes30.html#rnfb30-security-encryption
--
Mark Rotteveel

Ertan Küçükoglu

unread,
May 4, 2024, 8:22:59 AM5/4/24
to firebird...@googlegroups.com
Hello,

You didn't write which version of FirebirdSQL you are using. As already indicated, you will need at least v3.0 or higher for database file level encryption support.
It may be possible to write your own encryption plugin.
You may want to check https://github.com/FirebirdSQL/firebird/tree/master/examples/dbcrypt for C++ and Delphi code examples.
These examples are very basic, but should be enough to understand the way how FirebirdSQL encryption works and can be developed.

Thanks & Regards,
Ertan

hassanein issa <conh...@gmail.com>, 4 May 2024 Cmt, 13:44 tarihinde şunu yazdı:
--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/d9e3056f-79c4-4997-b4a4-9dfae6cf1e39n%40googlegroups.com.

Dimitry Sibiryakov

unread,
May 4, 2024, 9:25:05 AM5/4/24
to firebird...@googlegroups.com
hassanein issa wrote 04.05.2024 12:40:
> Additionally, existing third-party solutions are prohibitively expensive for our
> small to medium-sized healthcare agencies.

According to the Google an average monthly salary in Iraq is estimated around
$500. In comparison a license for encryption plugin by IBPhoenix costs about
$140. Something doesn't match.

--
WBR, SD.

Elmar Haneke

unread,
May 6, 2024, 6:03:28 AM5/6/24
to firebird...@googlegroups.com

The current version of Firebird SQL does not offer a robust file encryption feature; it only provides column-level encryption, which is insufficient for our needs.

Versions 3, 4 and 5 do have documented support for encryption plugin to encrypt data pages.

For very old version 2.5 (and before) the (undocumented) encryption support is disabled by default. It is possible to reactivate it, but it should be a waste of time to do so for an outdated database.

Additionally, existing third-party solutions are prohibitively expensive for our small to medium-sized healthcare agencies.

You are free to write your own Plugins, it's only some hundred lines of code in c++ with a simple implementation. 

IBSurgeon's framework offers certainly more flexibility that is not strictly required.



  

Hamish Moffatt

unread,
May 6, 2024, 7:51:16 PM5/6/24
to firebird...@googlegroups.com
On 4/5/24 20:40, hassanein issa wrote:
>
> Dear Firebird SQL Developers,
>
> I am writing on behalf of several Iraqi Firebird users who are the
> providers of healthcare programs and databases. We are in urgent need
> of a comprehensive on disk all database file encryption feature in
> Firebird SQL to meet the new legal requirements for data security in
> the healthcare industry in Iraq. Failure to provide this feature would
> sadly force us to discontinue our use of the Firebird database, which
> we currently find fantastic, and reluctantly switch to alternative
> solutions that offer free or low-cost encryption out-of-the-box (such
> as SQLite or MS Access).


What is the advantage to you of using database-level encryption versus
storing the database file on an encrypted file system?


Hamish

Ertan Küçükoglu

unread,
May 7, 2024, 1:42:56 AM5/7/24
to firebird...@googlegroups.com
Hello,

My knowledge;
- Encrypt file system is to protect against hardware theft. Person having access to an already running system can still make a copy of a plain readable database file.
- Encrypt database is to protect against database theft. Person having access to a database file will not be able to open it without the correct decrypt method.

Thanks & Regards,
Ertan

'Hamish Moffatt' via firebird-support <firebird...@googlegroups.com>, 7 May 2024 Sal, 02:51 tarihinde şunu yazdı:
--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

Dimitry Sibiryakov

unread,
May 7, 2024, 5:02:22 AM5/7/24
to firebird...@googlegroups.com
Ertan Küçükoglu wrote 07.05.2024 7:42:
> My knowledge;
> - Encrypt file system is to protect against hardware theft. Person having access
> to an already running system can still make a copy of a plain readable database
> file.
> - Encrypt database is to protect against database theft. Person having access to
> a database file will not be able to open it without the correct decrypt method.

You are wrong. Person having access to already running system can get the
information from encrypted database as well. Just because "running" means that
someone has a legit access to it and Firebird server performs decryption of data.

--
WBR, SD.

Elmar Haneke

unread,
May 7, 2024, 5:20:15 AM5/7/24
to firebird...@googlegroups.com

  You are wrong. Person having access to already running system can get the information from encrypted database as well. Just because "running" means that someone has a legit access to it and Firebird server performs decryption of data.

In theory, this is a weak point in database encryption and the reason there is no encryption plugin included in FirebirdSQL: It would be an easy job to modify that to log keys from legitimate access.


In practise the plugins generate some obsurity to make it difficult to get the keys.




Dimitry Sibiryakov

unread,
May 7, 2024, 5:23:32 AM5/7/24
to firebird...@googlegroups.com
Elmar Haneke wrote 07.05.2024 11:19:
> In theory, this is a weak point in database encryption and the reason there is
> no encryption plugin included in FirebirdSQL: It would be an easy job to modify
> that to log keys from legitimate access.
>
> In practise the plugins generate some obsurity to make it difficult to get the keys.

If you have access to running system, you don't need the keys, you can get
the information from the database directly.
You also need not to modify encryption plugin because you can modify Firebird
itself.

--
WBR, SD.

Elmar Haneke

unread,
May 7, 2024, 7:02:28 AM5/7/24
to firebird...@googlegroups.com

  If you have access to running system, you don't need the keys, you can get the information from the database directly.
  You also need not to modify encryption plugin because you can modify Firebird itself.

The Server does not see the real encryption key.

In Database there is the Key-Name stored. This name is public an read by the Server. 

The encryption plugin receives that name and sends some information to keyholder plugin.

Keyholder plugin sends some other information to client and receives an answer from there. This answer is processed to answer request of encryption plugin.

Only in the simple case encryption plugin sends keyname and receives clear encryption key.

Server can log every data plugins are sending to each other and to client.


Dimitry Sibiryakov

unread,
May 7, 2024, 7:07:37 AM5/7/24
to firebird...@googlegroups.com
Elmar Haneke wrote 07.05.2024 13:02:
> The Server does not see the real encryption key.

It sees the real decrypted data. Key is pointless, the data is the target.

> In Database there is the Key-Name stored. This name is public an read by the
> Server.
>
> The encryption plugin receives that name and sends some information to keyholder
> plugin.
>
> Keyholder plugin sends some other information to client and receives an answer
> from there. This answer is processed to answer request of encryption plugin.

It is not how this system works in Firebird currently. Interaction
client<->key holder happens way before interaction crypt plugin<->key holder and
when crypt plugin ask key holder for key the ability of key holder to interact
with client is already lost.

--
WBR, SD.

Elmar Haneke

unread,
May 7, 2024, 7:25:08 AM5/7/24
to firebird...@googlegroups.com

Am 07.05.24 um 13:07 schrieb 'Dimitry Sibiryakov' via firebird-support:
Elmar Haneke wrote 07.05.2024 13:02:
The Server does not see the real encryption key.

  It sees the real decrypted data. Key is pointless, the data is the target.
Ok modified server can decrypt the database (as a copy or in place) once a legitimate client unlocks it.

In Database there is the Key-Name stored. This name is public an read by the Server.

The encryption plugin receives that name and sends some information to keyholder plugin.

Keyholder plugin sends some other information to client and receives an answer from there. This answer is processed to answer request of encryption plugin.

  It is not how this system works in Firebird currently. Interaction client<->key holder happens way before interaction crypt plugin<->key holder and when crypt plugin ask key holder for key the ability of key holder to interact with client is already lost.

Really?
The callbacks given to the plugins are doing that communication.

Dimitry Sibiryakov

unread,
May 7, 2024, 7:40:51 AM5/7/24
to firebird...@googlegroups.com
Elmar Haneke wrote 07.05.2024 13:24:
> Ok modified server can decrypt the database (as a copy or in place) once a
> legitimate client unlocks it.

Even worse: unmodified server can do it as well.

> Really?
> The callbacks given to the plugins are doing that communication.

I found (by the hard way) that this callback cannot be stored to be used
later. It is valid only inside of keyCallback().
The only exception is embedded mode.

--
WBR, SD.

Reply all
Reply to author
Forward
0 new messages