FOR

Application Security's DbEncrypt is a tool providing a means of encrypting fields (conceptual 'rows' and/or 'columns') within Oracle database records. There are actually two ways of using the product, which itself provides strong modern encryption from among several methods, including AES (advanced encryption standard), Blowfish, CAST128 and CAST256, DES, triple-DES, DESX, Blowfish, MD5, RC2 and RC4 (compatible), RSA, Serpent, SKIPJACK, SHA1 and Twofish. The security and speed of these varies, and the administrator can select which method meets the system requirements.

The system defaults to AES encryption (using CTS mode) with a 128-bit key. DbEncrypt uses these several industry standard, royalty-free, time-tested encryption algorithms rather than any proprietary methods. This provides the dual assurance that you are not using a possibly half-baked flaw ridden technology, and that you will be able to migrate or add on other software and products without fear of unintentionally incorporating incompatibility into your database.

Strong encryption is frequently used today for actively transmitted data, securing it from loss, theft or distortion in transit - as for instance over the Internet or in a sophisticated multi-site network. Public key infrastructure (PKI) secures data, via authorization and actual encryption, through communications traffic, but does not take into account local security. DbEncrypt complements such network or Internet traffic security by incorporating encryption at the storage level - securing data on its source disk in the first place. If the database is physically compromised the hacker will find ciphered text rather than clear understandable data. Furthermore such local encryption will facilitate the prevention of accidental unauthorized access, and will decrypt data only under prescribed control (e.g. authorized passwords, named competent users).

It should be noted that even firewalls and intrusion detection mechanisms cannot secure a database against some forms of abuse. People who have restricted access to information in a database have potential means to hack further, and gain more information than was intended, all without trespassing network or operating system protocols. Data that is not secured at this application layer is vulnerable, but modern encryption methods, as incorporated within DbEncrypt, will help.

Even with the slowest of the provided encryptions, the impact on speed of access to data should be minimal, and yet the security it makes available is priceless. You need only encrypt data that should be restricted - for example financial or other sensitive collateral information about individuals in a database covering customer details. Encrypting and decrypting all the data in any one record ('row' of an enquiry table) may prove to be unduly time consuming, but DbEncrypt allows you to select what parts of the database will be kept encrypted. In particular it would be unwise to keep encrypted a field which is itself part of a frequently used key, because the system would have a greater overhead to decrypt such fields each time any index-related functions are performed. The available documentation gives good advice on what kinds of data should be encrypted, and further discusses the available encryption algorithms.

DbEncrypt is comprised of two parts: the console (and services available to programs) sits on a Windows NT 4.0 (SP3) or Windows 2000 platform equipped with at least 32Kb RAM, and requires 10Mb space on a hard drive. The Server Side Module of DbEncrypt supports encryption on Oracle databases (Oracle8i Enterprise Edition or Oracle9o Enterprise Edition). It runs on Microsoft Windows NT 4.0, Windows 2000, HP/UX, Linux or Solaris as a platform, with 150Kb RAM additionally for each client run concurrently.

You must be able to connect with an Oracle database in order to install the Server Side Module, perform any key management, or run any encryption scripts. You will also need to have Oracle Objects for OLE on the machine on which the Console is resident. The Server Side Module is actually installed by a procedure selected from the Console. The encryption and decryption of data is performed on the server. Even clustering is supported, so long as the DbEncrypt Server Side Module is installed on each database server.

You can perform key management from within the Console program, and several optional methods are made available. If the operating system is secure and supports it, you can elect to store key information in a system file (with limited permissions for access, provided by the operating system itself). If this method is employed, there is no need for each database user to have a password. Alternatively private keys can be kept (in secure encrypted form), typically on the hard disk of the processor running the Console. These provide the required link between a password entered by the user at a keystation, and the keys needed to encrypt and decrypt the selected database. A further option provides storage of authentication information alongside the database itself, on the server. This provides for a transparent implementation of DbEncrypt, wherein users need not specify passwords.

We were provided with three manuals accompanying the software: Product Feature Demonstration, DbEncrypt Getting Started Guide, and DbEncrypt User Guide. These are well planned, full of clear explanation as much as information, and we cannot fault them. Even more technical matter is available readily from Application Security, Inc.'s web site.
 

SC On-Line
SC Magazine
www.scmagazine.com