The traditional approach to data management has been to have a highly centralized big iron enterprise database engine that supports myriads of security options storing sensitive data. With these enterprise engines you have your choice of authentication, permissions, encryption, and other options to secure your data. As long as you have a database administrator that understands these options and can configure them properly, not as easy as it sounds, your data can be secured. However, data is starting to emerge from the data center and make its way to the outer nodes of the network.
Many of the devices on the outer node do not run hardware compatible with or capable of running a full-fledged enterprise DBMS with its array of security options. These outer nodes are starting to rely on embedded database engines. While embedded database engines are starting to resemble enterprise database systems that are not enterprise database systems and should not be enterprise database systems. This is a fact that my colleague Randy Merilatt eloquently pointed out in his article “Is using SQL in an embedded computer application like trying to squeeze an ELEPHANT into a MINI?”. What is a developer to do if they have data in an embedded database that requires a measure of security?
One common approach to security by embedded database engines has been obscurity. An embedded database is typically embedded in the internals of an application and only the application has any visibility to the data stored in the database. Security by obscurity is not effective when it is the only security measure available. It is easy enough to monitor file I/O and determine where on the file system an embedded database engine is writing data. A sufficiently motivated attacker will be able to reverse engineer any clear text file format and learn how to interpret the stored data. In addition, as embedded databases have taken on the characteristics of their enterprise brethren they have started allowing remote access. With the ability to access data remotely the need for authentication has also been introduced.
RDM 12.0 has added the ability to secure database content by adding database level encryption. The implementation of encryption in RDM allows for both authentication and obfuscation, although applications that do not require authentication can implement encryption in their application in a manner that does not require it. Understanding that our engine is used in a wide variety of applications running on a wide variety of hardware we have designed the encryption functionality to be flexible but focused. Providing robust security to meet the needs of embedded applications and devices without the computational and human resource overhead required by an enterprise engine.
To meet this goal Raima decided on using AES encryption for our data security solution. There are several reasons why AES is a good choice for Raima.
- It is an industry standard and highly secure algorithm
- It allows for several key sizes (128, 192, and 256 bits) to give our customers the flexibility to choose between higher security and higher performance.
- As a symmetric-key block cipher the number of bits of input match the number of bits of encrypted data
- There is public test data available to validate an AES implementation
- It allows Raima to provide a level of obfuscation and authentication
Raima’s encryption implementation provides data obfuscation by encrypting all data that is written to disk (including log files). Even if an attacker were monitoring file I/O to determine what files are updated by an application there is no way they could interpret the contents of those files without the correct encryption key. In addition to knowing the correct encryption key they would also need to know exactly how the file(s) are encrypted. For performance and practicality the database files are not encrypted as a whole, but rather they are encrypted in individual chunks. When you update a row in a table the engine only updates the chunk of the file that has the particular encryption block where the row is stored. This level of security can eliminate an attacker from reverse engineering the database files to discover the contents, but it does not eliminate the risk of an attacker using the application to read the data or writing an application with the RDM runtime to read the data. This is where authentication plays a role in security.
To create an encrypted RDM database the developer is asked to provide an encryption passcode. This passcode is put through a one-way hash to create an encryption key. This encryption key is used to encrypt the randomly generated key used to encrypt all database content. Simply put without the original passcode it is impossible to read the database contents. Any application that wants to read an encrypted database must provide the correct passcode, this includes all of the RDM utility applications as well as any application provided by the developer. When using an encrypted database a developer can be assured that only authorized users have access to the data stored in the RDM embedded database.
Learn more about Raima’s Encryption