User:BevFinch/sandbox

From Wikipedia, the free encyclopedia

What is Database Encryption[edit]

Database encryption pertains to a process in which database data is converted into worthless codes to prevent unwanted access to everyone who doesn’t have the privilege to the encryption keys. It is basically a technique used solely to prevent unwanted access to a database.


Idea behind Database Security[edit]

Database security covers three major components: availability, integrity, and confidentiality. The three components are self explanatory in a database sense so to speak. The availability component guarantees database entry is consistent and on time. The Integrity component ensures that the database data will not be somehow damaged by some unforeseen circumstance(s). While the confidentiality component ensures that constraints place in the database beforehand is followed while the secured data is being used. Administering the access control procedures that’s set in the database management system (DBMS) is the most common or current way in maintaining the data confidentiality property. The fundamentals data model dictates the structure of the access control policy, (which are a predefined permissions), for instance it could take the form of XML or perhaps relational. Additionally, how permissions are executed through either a Discretionary access control (DAC), Role Based Access Control (RBAC) or Mandatory Access Control (MAC) also comes to play.

Although security personnel would rather avoid it all together, permissions administered by the database server can still be tampered through different tactics even with an access control model in placed. For instance, the information system can be breached by querying the database footprint through a disk. Another issue is that it’s common to hire an outside company to host the database or use Database Service Providers (DSP). In this situation, the database protection is left to the care of the DSP’s, which means that data owners has to trust that whatever the DSP’s stated about their security is true and that the DSP’s security is beyond breached from both the outside and inside including the company employees. Last but not the least, though most Database Administrators (DBA) are trustworthy, there are some that will break that trust and tamper the access control definition. [1]

In keeping with some of the traditional encryption principle, defense in depth means putting different methods or policies of protection on top of one another so that if an intruder wants to intrude the database, it must have to go through layers after layers of protection. With defense in depth in mind, incorporating the access control with cryptographic methods to strengthen security has garnered many interests from the database group. [2] [3]

Database encryption primarily intention is to foil any attacks from any intruders by hiding the database data to those who may want to do harm it. But if for some reason intruders can somehow breached the firewall and access control policies, it still won’t do any good since encryption keys are still needed to decrypt the data. Indeed database encryption can keep data at rest secure, but planning and implementing is easier said than done since there are multiple variables to take into account; such as the level where the encryption should take place, should it be placed in the storage, in the database, or in the application layer where data is created?. What would suffice ample database security, and what data should be covered or not covered? What route should be taken or strategy to take when it comes to deciding about encryption algorithm and method of process? To whom the encryption keys should be entrusted to and to what extent? What methods or procedures to take to lessen the effects of database encryption on performance? These are among the many questions that one must think before undertaking database encryption.

Encryption Levels[edit]

Storage-level encryption[edit]

This type of encryption secures data at rest, and prevents unwanted access or pilfering of media and storage systems. Storage level encryption is suitable for encryption of files or the whole index in the operating system framework. In database sense, this type of encryption can be applied without modifying applications in any way since the encryption/decryption occurs in the path of the data. But the disadvantage is that the encryption can’t be associated with user permissions or grants, such as unique encryption keys pertaining to unique users, as well as database sensitivity since the part of the database that’s encrypted is unaware of the database matter and composition which is the decrypted part on this type of encryption. As a result of only encrypting particular parts of the database in order to minimize the effects of encryption overhead, the file scope is inadequate. Additionally, encrypting only certain portion of the database can pose a security risk because one might missed that a copy (perhaps that exist in the temporary and log files) of sensitive data remains unencrypted.

Database -level encryption[edit]

This type of encryption enable enterprises to secure data from the database as it is being written or read. Database level encryption can certainly foil theft of essential data, especially if it is incorporated with database security and access control. Database level encryption is usually applied at the column level inside the database table. The intent of database level encryption is to secure the data inside DBMS as well as preventing different kinds of security breached such as storage media thief, well known storage attacks, database-level attacks, and spiteful DBA’s. Database encryption doesn’t require any application alteration that is usually associated with application level model. Furthermore, the popular method of attaching business logic inside DBMS by means of employing stored procedures and triggers is facilitated in this level. Encrypting /decrypting in this level eliminate the need of the enterprise to know or be aware of the access attributes or applications of the data that is being encrypted because the process is solely executed inside the database. For this method to be effective, incorporating work within the database level, such as changes to the existing database schemas as well as the usage of triggers and stored procedures to carry out encrypt and decrypt functions becomes necessary. Performance may suffer especially if the support for augmented index search on encrypted data is absent, that’s why it is particularly essential that when applying this type of encryption method, best judgment must be applied. Enterprises therefore should take up a rule of only encrypting sensitive fields. Additionally, making hardware work in order to add to the level of security and to offset any performance effects due to cryptographic process is advisable. Due to the fact that this type of encryption is solely executed inside DBMS, it does not offer protection against malicious attacks in the application level.

Application-level encryption[edit]

Application level encryption secures the data individually at the application level and implement the encryption/decryption method within the application level. For instance, when sensitive information is received, the data is encrypted while the process of protecting the data by the application is on going. The data is kept and will stay encrypted until it’s time for the application to decrypt it. In essence, this type of encryption doesn’t protect or cover all; the encryption is usually much specific to the protection of sensitive data (such as credit card information), which could leave a large portion of the data vulnerable to attacks. But since this encryption protects data that matters anyway, the fact that it covers only a portion of the data might not be a problem. Because keys are always inside the application, it offers the advantage of having the encryption keys and the encrypted data to not be in the same place in the database which can be a good thing. This advantage though is not design by default; application has to be altered in order for the advantage to be applicable. Moreover, sometimes there is an instance where the application gives a user more data than what the users has permission for, which can pose a security threat. As such, a user or an attacker who has malicious intents can gain entry to the computer where the application happens to be running. Lastly, this approach can sometimes have an effect on database performance, as well as prohibit the usage of some functions such as stored procedures, or triggers. The prohibition could pose a problem for Database Administrators since triggers and stored procedures are essential part of Administrators functions. In general, when it comes to scope and key management, application level encryption offers the most benefits in terms of flexibility because the application logic can dictate the encryption scope and encryption keys. [4][5][6]

Form of Operation and Protection Algorithm[edit]

Putting aside what encryption method is use, encryption algorithm, size of the encryption key and the protection it uses dictates how secure the encrypted data is. Inapt method can still reveal plain text information through cipher text, in spite having strong algorithms or AES. For instance if electronic codebook form (ECB) is executed through the use of encryption algorithm, similar plaintext blocks are encrypted inside the similar cipher text blocks, therefore revealing the recurring patterns. Recurring pattern is not a big deal in the database world since occurrence of records sharing the same attribute occurs frequently therefore picking the right encryption form should not be taken lightly. Additionally, simplified solution that worked on a framework might not work on another. For example applying counter form along with the initialization vector according to data addresses might work on one database, but fall short on another. To ensure that encryption algorithm, means of procedure, patterns updates, and large quantity of encrypted data is applied sufficiently, each of the precise frameworks of the database must be carefully accounted for. Encryption algorithm and manner of procedure should be advanced and applied without comprising any part of the protection. Lastly, data can last for along time (think in terms of years), so the applied protection must be able to stand the test of time.

Key Management[edit]

Key management pertains to how cryptographic keys are created and handles over its life span. Due to the fact that cartography is established on keys which encrypt and decrypt information, the quality or how secure the database is will depend on how well the keys are protected. Where the keys are kept and who has access to them is crucial. The proceeding mitigation only applies to database level because the predicament is unrelated to encryption level. To mitigate the issue in database level encryption, a restricted database table or file that is perhaps encrypted by a master key which is hidden on the database server can be created. But keep in mind that administrators with the right access can still access the keys and decrypt any data inside the system without being noticed.

To mitigate this issue, there is a specialized beyond breached cryptographic chipsets which is called hardware security module (HSM). It can be used to store encryption keys and keep it hidden from unauthorized users. Encryption keys are normally kept in the server which is encrypted by a master key that is placed in the HSM. When the encryption and decryption occur, encryption keys are decrypted by the HSM with the help of the master key. After the cryptographic process, it is immediately deleted from the server memory [7] [8]

If HSM is not suitable, there is another way. The other option is to have security related task transferred to discrete software that is running on a physically discrete server; the server is called security server. Users, roles, privileges, encryption polices and encryption keys are then left to the care of the security server which is probably dependent on a HSM. The security module exchanged information with the security server to check for privileges, encrypt and decrypt the data, and verify the validity of the users inside DBMS. Users’ privileges or a user is then linked to their designated encryption keys. A clear separation of roles is also established between the difference of DBA which administers database resources, and Security Administrators or SA which administer the security parameters. For a database breached to be successful, the Security Administrator and the Database Administrator must be in cohort in order for the attack to go through.

Take note that even with the addition of security server and or the HSM it does not fully guaranteed that the database will be completely secure. For a short moment, the encryption keys and the decrypted data may leave a remnant within the database server memory and is vulnerable for attacks.

Applications[edit]

For a few years now, majority of DBMS manufacturers enable a capability in which application developers can add more layers into the data security through selective encryption into the stored data. The native functionalities are in the form of encryption toolkits or packages for Oracle 8i/9i. [9] The functions were attached in SQL queries such as IBM, DB2, [10] or the extensions of SQL for Sybase [11], and SQL Server 2005 [12]


Performance overhead can be minimized by using selective encryption which can be created at the column level, but might include changes in schema in order to incorporate binary data due to the encryption process [13]. Transparent data encryption (TDE) was launched by SQL Server 2008 [14]. This type of encryption resembles how storage level encryption works. A single key called DEK for Database Encryption Key, secures the entire database, DEK in turn is secured by multiple complicated layers of protection, including perhaps through HSM. TDE manages and execute all of the cryptographic operations in the I/O level, and inside the database system which eliminates the need for customized code to encrypt and decrypt data usually created by the application developers.

TDE which shares its name with SQL Server but doesn’t share the same capabilities, surfaced in Oracle 10g/11g. The addition made doing cartography inside the DBMS possible, and made HSM able to managed the encryption keys or kept in an outside named holder that is encrypted with an administrative discrete password [15]. Column scope or perhaps larger such as table space (which is a group of files pertaining to one or more tables and indexes), must be used if one wants to do selective encryption. Oracle once suggested that in order to go around the encrypted data analysis; salt, random 16 bytes of string accompanying each of its encrypted attribute value must be incorporated into the encryption process. The prospect of using encryption form which impartiality in the CBC form in a regular start up vector is conserved, therefore enabling for example, the usage of indexes for parity based on encrypting the searched value is considered a dangerous element.

The preceding database level encryption with security server approach is suggested by IBM DB2 along with the data Encryption Expert (DEE [16]) and by third party vendors such as Protogrity [17], and RSA BSAFE [18]. Oracle, IBM, DB2, SQL Server and Sybased are mostly compatible with third party vendors’ products.

Open Problems and future directions[edit]

Encryption Scheme[edit]

Though the current commercial database products take the standard encryption algorithms approach in database encryption, the uses of specific encryption schemes have gotten much attention from the academic field, most importantly in the Database as a Service pattern. Uninterrupted devices to produce save and access databases from the host site are the services facilitated by the database servers in this pattern. Additionally, managing data without the use of encryption keys (the same as the application level encryption) by the database server is possible with this pattern. [19]


"Homomorphic encryption is a form of encryption which allows specific types of computations to be carried out on ciphertext and obtain an encrypted result which is the ciphertext of the result of operations performed on the plaintext. For instance, one person could add two encrypted numbers and then another person could decrypt the result, without either of them being able to find the value of the individual numbers. Homomorphic encryption schemes are [malleable] by design. The homomorphic property of various cryptosystems can be used to create secure voting systems in Riyest (as cited in [20] collision-resistant hash functions, private information retrieval schemes and enable widespread use of cloud computing by ensuring the confidentiality of processed data. There are several efficient, partially homomorphic cryptosystems, and two fully homomorphic, but less efficient cryptosystems. Although a cryptosystem which is unintentionally homomorphic can be subject to attacks on this basis, if treated carefully homomorphism can also be used to perform computations securely."[21]


Another method which is considered a standard classical protection algorithm, is storing any other supplementary information that is categorized as unclear beside the cipher text to enable some query processing in the protected text. In essence, this route should prevent plain text content from revealing itself, in which a balanced exists between security and being efficient. [22] [23].

New database encryption strategies[edit]

Since encryption keys are present in plain text of the RAM in the server or in the end users machine, the present architecture to include database encryption doesn’t suffice. To reduce the likelihood of key exposure, HSM function as a protector all through the keys lifespan. There is an on going research in order to apply HSM in better way, eliminating the need for the key to be exposed altogether. Two better ways have been found; one is server-HSM which is placed in the server and used by many end users simultaneously, the second one is client HSM which is placed on the end users computer and only the user can access it.

In essence, server_HSM mimics the database level encryption, but with a security server attached to it in the HSM. Users, privileges, encryption guidelines and keys become HSM responsibilities. Due to the fact that encryption/decryption is process inside HSM, encryption keys are not vulnerable on any given moment, and have the same benefits with database level encryption but with a server approach to it. Additionally it is impossible to breach the security server since it is completely merged inside the tamper resistant HSM. Query results delivered to the user(s) is the only data that is displayed in plain text. There is one main issue with this strategy though; since the HSM requires a complicated piece of software attached to it, which has a very limited calculation resource due to security concerns, adopting this approach is quite challenging.


Although client HSM methods are very much alike with server HSM methods, as well as having the same advantages when it comes to security, it does however present a few problems of its own. Since it is dedicated to a particular client machine, close collaboration between the database server and the HSM might be challenging. Regardless of the issues that comes with this approach, this method is considered practical because it requires minimal resource and code is much more simplistic, which in turn placed less demand on resource. [24]


Other Security Issues[edit]

Encrypting data encompasses data protection, but doesn’t warranty data integrity, providing the data has not been tampered or alter through unwanted access (authenticity), or if the data is a newer version (freshness). Additionally when performing a query, It would be wise to make sure that the results are complete and accurate. A good indication if the database data has been compromised due to database server breached or other reasons are through query results, (providing the query syntax used to retrieve the data is correct). Another way to check wither the database data is reliable is through the use of cryptographic hash functions which is part of cryptographic techniques. Cryptographic hash functions are good and reliable methods to check for data reliability. Message Authentication Code (MAC) coupled with Merkle Hash Tree or MHT, can be utilized to ensure data is compete and accurate. [25]


To ensure data is up to date or current is challenging at times especially if the person(s) who is responsible in keeping it current is not the same person(s) that does the update of the data. Completely relying on cryptographic techniques to ensure that database data is accurate and complete has a negative impact on the database size and performance. In Oracle 11g for instance, TDE has to put 20 bytes of MAC onto the database for each encrypted attribute value. That’s why there is a current research to find a better way on dealing with this particular issue. One of the methods that came out from the research is called Database as a Service also called DAS context[26] To alleviate the effects of major bottleneck restrictions caused by the MHT, which can cause data updates delay, a signature based authentication method was created. [27] For outsourced database, some forecasting or statistical methodology can be utilized to check its data reliability. [28]

References[edit]

  1. ^ Hacigümüs H., Iyer B., & Mehrotra S. (nd). Providing Database as a Service. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.5693&rep=rep1&type=pdf
  2. ^ Hacigümüs H., Iyer B., & Mehrotra S. (nd). Providing Database as a Service. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.5693&rep=rep1&type=pdf
  3. ^ Rakesh Agrawal , Jerry Kiernan , Ramakrishnan Srikant, & Yirong Xu (2002). Hippocratic databases. Proceedings of the 28th international conference on Very Large Data Bases, pp.143-154. Retrieved from http://www.vldb.org/conf/2002/S05P02.pdf
  4. ^ Hacigümüs H., Iyer B., & Mehrotra S. (nd). Providing Database as a Service. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.5693&rep=rep1&type=pdf
  5. ^ Ernesto Damiani, S. De Capitani Vimercati, Sushil Jajodia, Stefano Paraboschi, & Pierangela Samarati (October 2003). Balancing confidentiality and efficiency in untrusted relational dbms. Proceedings of the 10th ACM conference on Computer and communications security, ACM, 2003, pp. 93-102. doi:10.1145/948109.948124. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.7806&rep=rep1&type=pdf
  6. ^ Luc Bouganim & Philippe Pucheral (2002). Chip-secured data access: confidential data on untrusted servers, Proceedings of the 28th international conference on Very Large Data Bases. pp. 131-142. Retrieved from http://www.vldb.org/conf/2002/S05P01.pdf
  7. ^ Sung Hsueh (February 2008). Database Encryption in SQL Server 2008 Enterprise Edition, SQL Server Technical Article. Retrieved from http://msdn.microsoft.com/en-us/library/cc278098%28v=sql.100%29.aspx
  8. ^ Paul Needham (June 2007). Oracle Corporation, Oracle Advanced Security Technical White Paper. Retrieved from http://www.oracle.com/technetwork/database/security/advanced-security-11g-whitepaper-133635.pdf
  9. ^ na (February 2001). Oracle Corporation, Database Encryption in Oracle9i, technique white paper. Retrieved from http://www.cgisecurity.com/database/oracle/pdf/f5crypt.pdf
  10. ^ na (Dec, 2007). IBM corporation, IBM Database Encryption Expert: Securing data in DB2. Retrieved from ftp://ftp.software.ibm.com/software/data/db2imstools/whitepapers/IMW14003-USEN-01.pdf
  11. ^ na (2005). SYBASE Inc, Sybase Adaptive Server Enterprise Encryption Option: Protecting Sensitive Data. Retrieved from http://www.sybase.com/content/1036205/SybaseASE_Encryption-041906-DS.pdf
  12. ^ Sung Hsueh (February 2008). Database Encryption in SQL Server 2008 Enterprise Edition, SQL Server Technical Article. Retrieved from http://msdn.microsoft.com/en-us/library/cc278098%28v=sql.100%29.aspx
  13. ^ Sung Hsueh (February 2008). Database Encryption in SQL Server 2008 Enterprise Edition, SQL Server Technical Article. Retrieved from http://msdn.microsoft.com/enus/library/cc278098%28v=sql.100%29.aspx
  14. ^ Sung Hsueh (February 2008). Database Encryption in SQL Server 2008 Enterprise Edition, SQL Server Technical Article. Retrieved from http://msdn.microsoft.com/enus/library/cc278098%28v=sql.100%29.aspx
  15. ^ Paul Needham (June 2007). Oracle Corporation, Oracle Advanced Security Technical White Paper. Retrieved from http://www.oracle.com/technetwork/database/security/advanced-security-11g-whitepaper-133635.pdf
  16. ^ na (Dec, 2007). IBM corporation, IBM Database Encryption Expert: Securing data in DB2. Retrieved from ftp://ftp.software.ibm.com/software/data/db2imstools/whitepapers/IMW14003-USEN-01.pdf
  17. ^ Ulf T. MATTSSON (June 2004). Transparent Encryption and Separation of Duties for Enterprise Databases: A practical implementation for Field Level Privacy in Databases, Protegrity Technical Paper. Retrieved from http://papers.ssrn.com/sol3/papers.cfm?abstract_id=571422
  18. ^ na (2002). RSA Security Inc. Securing Data at Rest: Developing a Database Encyption Strategy. A white Paper for Developers, e-Business Managers and IT. Retrieved from http://www.rsa.com/products/bsafe/whitepapers/DDES_WP_0702.pdf
  19. ^ Hacigümüs H., Iyer B., & Mehrotra S. (nd). Providing Database as a Service. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.5693&rep=rep1&type=pdf
  20. ^ na (June 23, 2012). Homomorphic encryption. Retrieved from http://en.wikipedia.org/wiki/Homomorphic_encryption
  21. ^ na (June 23, 2012). Homomorphic encryption. Retrieved from http://en.wikipedia.org/wiki/Homomorphic_encryption
  22. ^ Hacigümüs H., Iyer B., & Mehrotra S. (nd). Providing Database as a Service. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.5693&rep=rep1&type=pdf
  23. ^ Ernesto Damiani, S. De Capitani Vimercati, Sushil Jajodia, Stefano Paraboschi,& Pierangela Samarati (October 2003). Balancing confidentiality and efficiency in untrusted relational dbms. Proceedings of the 10th ACM conference on Computer and communications security, ACM, 2003, pp. 93-102. doi:10.1145/948109.948124 Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.7806&rep=rep1&type=pdf
  24. ^ Luc Bouganim & Philippe Pucheral (2002). Chip-secured data access: confidential data on untrusted servers, Proceedings of the 28th international conference on Very Large Data Bases. pp. 131-142. Retrieved from http://www.vldb.org/conf/2002/S05P01.pdf
  25. ^ Feifei Li, Marios Hadjieleftheriou, George Kollios, & Leonid Reyzin (June 2006). Dynamic Authenticated Index Structures for Outsourced Databases. Proceedings of the 2006 ACM SIGMOD International Conference on Management of data, ACM, pp. 121- 132. doi:10.1145/1142473.1142488 Retrieved from http://www.cs.bu.edu/~reyzin/papers/auth-db.pdf
  26. ^ Hacigümüs H., Iyer B., & Mehrotra S. (nd). Providing Database as a Service. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.5693&rep=rep1&type=pdf
  27. ^ HweeHwa Pang, Jilian Zhang, & Kyriakos Mouratidis (August 2009). Scalable Verification for Outsourced Dynamic Databases. Retrieved form http://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=1875&context=sis_research
  28. ^ Min Xie, Haixun Wang, Jian Yin, & Xiaofeng Meng (September 2007). Integrity auditing of outsourced data. Proceedings of the 33rd international conference on Very large data bases, pp. 782-793. Retrieved from http://www.haixun.olidu.com/publications/vldb07.pdf
















See also[edit]

[[17]]

External links[edit]

Vormetric encryption

Cloud encryption

Data Encryption breakthrough

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:BevFinch/sandbox&oldid=510945721"