FCBHifence software provides cell level data security via public-key cryptography (also known as asymmetric cryptography) for on-premises or cloud based, Express, Standard or Enterprise, 11g, 12c, 18c or 19c Oracle databases.


The purpose of this software is to provide highest possible level of data protection for sensitive information like ePHI (US), GDPR (EU) or PCI related. Because of that FCBHifence software doesn’t use symmetrical cryptography like AES or DES, but asymmetrical like RSA or DSA.

Key features

  • Cell level encryption
  • SQL and PL/SQL data types, i.e. string, varchar, nvarchar, clob, nclob supported
  • GNU Privacy Guard cryptography engine used
  • Data access separation
  • Main code is written in PL/SQL language. External modules are written in shell and JAVA languages
  • Single and multi-byte char sets supported
  • All editions of Oracle 11g (excepting XE), 12c, 18c and 19c database (including multi-tenant container databases)
  • DBaaS  compatible
  • External database key storage. No any keys stored within constant database objects
  • No any key operations inside database or database memory
  • Distributed key management
  • Major UNIX distribution (IBM AIX, SUN/Oracle Solaris, Linux) supported
  • Simplified BSD License

How it works

FCBHifence software doesn’t reinvent wheel and uses GNU Privacy Guard software (GnuPG). GnuPG (or compatible to IETF standards-track specification of OpenPGP software) must be installed as on server side so on user computer. Key management operations, i.e. creation, deletion, expiration, import, export are performed by GnuPG only. Data operations as encryption and decryption are performed by the GnuPG also. FCBHifence software can be considered as a bridge between the GnuPG (or software with the similar functionality) and Oracle database.

Data routines. Without being lost in too much details asymmetrical encryption bases on two kinds of security keys: public and private. Public key is used to encrypt data. Private key is used to decrypt data. They both is the pair. User, who authorized is to decrypt and therefore to read data, stores private key in GnuPG guard key storage on the user computer. Public key is stored on the server or on the user computer in the GnuPG key storage also. Keys can be exported and imported to/from the GnuPG key storage. Thus any cell level data in an Oracle table can be encrypted by the different public keys to provide data separation, i.e. one column can contain differently encrypted rows. Only application having access to the local key storage, where paired private key is stored, can decrypt data.


There are no ways to store asymmetrically encrypted data in Oracle table data types like date, timestamp, float, number.


What’s new

  • Apr 24, 2019. 31 initial build released
  • May 15, 2019. 31 build supports Oracle 19c


Found a bug? Please use this link to report.

Questions? Propositions? Comments? Let me know what you think via email