InfinityDB Encrypted is identical to InfinityDB Embedded, but is also 100% encrypted 100% of the time
This encryption and security edition is in beta testing – please email firstname.lastname@example.org.
Transparent Data Encryption
InfinityDB Encrypted uses ‘Transparent Data Encryption’ or TDE to minimize the impact of security. It is necessary only to provide a password on file creation and opening, and all the rest is handled internally. You can combine this TDE with other security measures to increase safety. Because InfinityDB uses a single file for all data in a given database, the encryption covers all data at once reliably, even while in use. The encrypted files can be used as backups with no encryption step, and with no decryption on restore. There is no point in time when any unencrypted data reaches storage.
- All stored block data is 100% encrypted 100% of the time according to a password using AES-128 or AES-256
- All stored block data and header is 100% authenticated 100% of the time according to the password using HMAC SHA-256
- Selectable encryption levels – strong or regular for export compliance. Future versions will provide more
- File content is fully dynamic – there is no ‘encrypted’ vs ‘unencrypted’ state and open() is fast
- Optional signing ensures a guaranteed overall file content. Backups are therefore authenticated and safe from external modification
- Selectable signing algorithms such as SHA256 with RSA, DSA, or ECDSA
- Multiple X509 certificates and their trust chains or bare public keys are stored in the file and organized automatically
- Partial signing by different processes will finally reach fully signed state; not all private keys are needed at once
Compatible with InfinityDB Embedded
- The API is a superset of the InfinityDB Embedded API
- No performance hit
- Compression is preserved
- Unencrypted files are compatible – they can still be opened for read or write and stay unencrypted
Each block is separately encrypted and authenticated with a secure random initialization vector according to the password based on AES and SHA-256. The block numbers are encrypted and authenticated per-block as well. Every write of a block changes its stored data completely and randomly, even for partial block changes. Corruption or truncation of a file is immediately detected on read of a corrupted block, or on signing or signature verification or on a request for computing the overall encrypted block hash.
A global SHA-256 hash can be calculated quickly on demand, dependent on only the block data, i.e. the ItemSpace content, but independent of the signature setup or state or other header data. This hash is what is actually signed.
Multiple certificate chains and bare public keys can co-exist in the file header. Automatic certificate organization features like duplicate certificate elimination, trust chain pattern checking, and chain sorting are provided. Chains are verified to have valid and complete internal signing structure. Signature verification does not require the encryption password. The signing and signature verification hashes the full set of encrypted data blocks at high speed. Signatures persist until block data actually changes, so multiple signers do not need to have the file open at once. Signing requires only providing the signer’s private key or keys and then invoking sign(), and the private key or keys are automatically matched to the public keys of certificates that are signed. Signature verification (currently) requires that all certificates are signed.
InfinityDB Encrypted has been tested with the Sun security provider as well as Bouncy Castle. Bouncy Castle is the main alternative to Sun, and it adds many features, such as a complete certificate generation capability.
Other DBMS have tried to retro-fit security, but there are so many remaining issues that the security is still weak or non-existent. Applications, users, and DBAs have to pay considerable attention in order to provide credible protection. It is necessary to pay attention to text log files, transaction logs, backups, slaves, temporary files like sort areas, index content, and any other kind of dangling dumps or copies and so on. In fact in most environments, the data can become so distributed and duplicated that credible security is almost impossible. Encrypted disks and file systems are helpful, but there is no enforcement for their use, and data can ‘leak’ out, even just because of files not being zeroed or ‘bleached’ before deletion. Rewriting applications to handle security at the application level can be very complex and can impose burdens on everyone. In any case, security can be improved by adding or switching to InfinityDB Encrypted.
- Enveloping. This allows the file’s single encryption password – the ‘Password-Based Encryption’ or ‘PBE’ password – to be accessible only to selected accessors based on public/private key pairs. A set of Envelope certificates are kept in the file, and for each, there is an encrypted copy of the PBE password in the file. The PBE password can be decrypted by the owner of the private key for an envelope certificate. So, instead of keeping track of potentially many PBE passwords, one per file, a given private key can be used to access a whole set of files that have the proper envelope certificate. Since the PBE passwords are no longer necessarily exposed externally, they can be very long and strong, even non-user readable. Because a given file can have multiple envelope certificates, access control is flexible and tight, yet simple.
- Multi-threaded data block hashing for signing and signature verification to reach very high speeds.
- Trusted cert verification – currently the cert chains are not checked to end in a cert in a given trust store. (Bug) Instead, clients check for certs they trust explicitly, i.e. ‘pinned’ certs.
For info and suggestions please email email@example.com.