Download database level encryption

NAYAK 1
NEEL NAYAK
JOSEPH MCGINNIS
IS-610
12/15/2015
DATABASE ENCRYPTION
Related Concept Keywords:
Database security, Encryption, Data confidentiality, Hardware Security Module.
Definition:
Database encryption refers to the use of encryption techniques to transform
a plain text database into a cipher text database (public key and private key), thus
making it unreadable to anyone except those who possess the knowledge of the
encryption keys.
Theory:
Hackers are bypassing traditional security organizations practically
voluntarily, breaking frameworks in a wide swath of commercial enterprises and
topographies. In this subsequent meet-up our notable May 2014 report,
"Cybersecurity's Maginot Line. It can along these lines be said that the reason for
database encryption is to secure the information put away in a database from being
gotten to by people with possibly "malignant" goals. The demonstration of encoding
a database additionally lessens the motivating force for people to hack the previously
stated database as "aimless" scrambled information is of next to zero use for hackers.
There are numerous strategies and innovations accessible for database encryption,
the most vital of which will be point by point in this article.
NAYAK 2
In order to maintain Confidentiality, Integrity and Availability there are three level
of database encryption; Storage - level encryption, database level encryption and
application level encryption. Lets us know discuss about these levels.
Figure 1 database encryption schema
STORAGE – LEVEL ENCRYPTION
Huge number of today's security orders require ensuring information very still, and
capacity level encryption is one vital approach to fulfill this. Storage media are
especially powerless against misfortune and theft. Going down information to tape,
for instance, is a period regarded and savvy approach to safeguard profitable data,
yet tapes can be lost, stolen, or lost, and the utilization of outsider offsite offices
expands the danger. The same can be valid for plate drives and even strong state
circles where equipment is much of the time sent off site for repair or redeployment.
Inability to viably wipe or devastate information already expands the danger of
presentation. Given these dangers, encryption of put away information is a
NAYAK 3
compelling method for ensuring data—and an organization's notoriety. Storage level
encryption guarantees that if stockpiling media are lost or stolen, their information
is useless to cheats, so organizations abstain from making humiliating information
break exposures. This sort of security is advantageous regardless of whether the
information being referred to is secured under protection laws or other industry
orders, for example, PCI DSS (audit for online transaction security gateway) . A few
specialists contend that all stockpiling frameworks ought to be encoded of course,
in the event of some unforeseen issue. Off-site documenting firms and dispatches
are notwithstanding beginning to dismiss decoded tapes or charge a premium to
cover their expanded danger. Indeed, even in this way, numerous organizations don't
scramble stockpiling media. They stress that encryption will moderate their
reinforcement procedures or make it difficult to get to the information later on if
encryption keys are lost.
Storage encryption required the utilization of committed stockpiling
apparatuses that expanded multifaceted nature and could affect execution. In any
case, with such clear business advantages, the capacity business has reacted; today,
implanted encryption abilities are incorporated with numerous capacity gadgets or
are accessible as arrangement alternatives. Yet, with more noteworthy utilization of
these capacities comes a comparing test—overseeing encryption keys over a
heterogeneous populace of gadgets. Associations need to oversee keys for the
duration of their life cycles, both to shield keys from unapproved use and to
guarantee that those keys are ensured to be accessible to honest to goodness clients
when required. As associations convey stockpiling gadgets from a scope of
merchants, consideration quickly turns from the encryption process itself to the test
of effectively dealing with the keys over those frameworks.
NAYAK 4
DATABASE LEVEL ENCRYPTION
Amounts to scramble information in the capacity subsystem and along these lines
ensures the information very still (e.g., from capacity media burglary). It is
appropriate for encoding records or whole catalogs in a working framework setting.
From a database point of view, stockpiling level encryption has the favorable
position to be straightforward, in this way maintaining a strategic distance from any
progressions to existing applications. On the other side, subsequent to the capacity
subsystem has no information of database questions and structure, the encryption
methodology can't be connected with client benefits (e.g., utilizing particular
encryption keys for unmistakable clients), nor to information affectability. In this
manner, specific encryption – i.e., scrambling just parcels of the database keeping in
mind the end goal to diminish the encryption overhead – is restricted to the document
granularity. In addition, specifically encoding records is hazardous since one ought
to guarantee that no copy of touchy information remains decoded (e.g., in log
documents, transitory records, and so.
Cryptographic Key Hierarchy for database level encryption.
At the root of encryption tree is the Windows Data Protection API (DPAPI), which
secures the key hierarchy at the machine level and is used to protect the service master key (SMK) for the database server instance. The SMK protects the database master key (DMK), which is stored at the user database level and which in turn protects
certificates and asymmetric keys. These in turn protect symmetric keys, which protect the data. TDE uses a similar hierarchy down to the certificate. The primary difference is that when you use TDE, the DMK and certificate must be stored in the
NAYAK 5
master database rather than in the user database. A new key, used only for TDE and
referred to as the database encryption key (DEK), is created and stored in the user
database.
This hierarchy enables the server to automatically open keys and decrypt data in both
cell-level and database-level encryption. The important distinction is that when celllevel encryption is used, all keys from the DMK down can be protected by a
password instead of by another key. This breaks the decryption chain and forces the
user to input a password to access data. In TDE, the entire chain from DPAPI down
to the DEK must be maintained so that the server can automatically provide access
to files protected by TDE. In both cell-level encryption and TDE, encryption and
decryption through these keys is provided by the Windows Cryptographic API
(CAPI).
APPLICATION LEVEL ENCRYPTION
Application-level encryption moves the encryption/decoding procedure to the
applications that produce the information. Encryption is consequently performed
inside of the application that brings the information into the framework, the
information is sent encoded, in this way actually put away and recovered scrambled,
to be at long last decoded inside of the application.
Attackers can use development tools, intended for tasks such as application
monitoring or debugging, to gain access to encryption keys or simply to turn off
encryption, unlocking information within the application.
When you encrypt information at the application level, you can protect sensitive data
and control access in a more fine-grained way than is possible with almost any other
form of encryption. In many ways the application is the obvious place to encrypt and
NAYAK 6
decrypt data because the application knows exactly which data is sensitive and can
apply protection selectively. The application frequently also knows about users,
roles, and entitlements and can provide access accordingly. Contrast this with
encryption used within storage systems, portable media, or networks, where data is
typically encrypted on an all-or-nothing basis because those systems have no
knowledge of data classes or specific user entitlements and therefore have limited
ability to be selective. Application-level encryption can be policy-based and geared
to specific data protection mandates such as PCI DSS. It can provide highly targeted
protection that is invoked only when necessary. This protection can be tightly
controlled and supervised, even requiring dual controls or other layers of procedural
protection that, taken together, directly support compliance reporting obligations.
Figure 2 Three layers of encryption a) storage level encryption b) database level encryption c) application level
encryption
NAYAK 7
KEY MANAGEMENT
The "Symmetric and Asymmetric Database Encryption" heading has presented the
idea of open and private keys with fundamental illustrations in which clients trade
keys. The demonstration of trading keys gets to be illogical from a logistically
perspective when various people need to correspond with one another. In database
encryption the framework handles the capacity and trade of keys. This procedure is
called key administration. In the event that encryption keys are not oversaw and put
away
appropriately,
exceedingly
touchy
information
may
be
spilled.
Figure 3 Cryptography
Furthermore, if a key administration framework erases or loses a key, the data that
was encoded through said key is basically rendered "lost" too. The multifaceted
nature of key administration logistics is additionally a subject that should be looked
into. As the quantity of utilization that a firm uses builds, the quantity of keys that
should be put away and oversaw increments also. Subsequently it is important to
build up a route in which keys from all applications can be overseen through a
solitary channel, which is otherwise called undertaking key management. Enterprise
Key Management Solutions are sold by an extraordinary number of suppliers in the
innovation business. These frameworks basically give a concentrated key
administration arrangement that permits chairmen to deal with all keys in a
framework through one hub. Thus it can be said that the presentation of big business
NAYAK 8
key administration arrangements can possibly decrease the dangers connected with
key administration in the setting of database encryption, and in addition to lessen the
logistical inconveniences that emerge when numerous people endeavor to physically
share keys.
Future strategies
Encrypting the information just ensures information secrecy, yet gives no
affirmation on information trustworthiness, i.e., on the way that the information has
not been illicitly fashioned or changed or supplanted by more seasoned renditions.
Moreover, if the database server is untrusted, (e.g., it may have been altered by
aggressors), one ought to check the question results rightness (results compares to
the inquiry determination) and fulfillment (no question result is absent).
Utilizing cryptographic methods "as-is" to give the previously stated certifications
has an extensive negative effect on the database size e.g., a 20 bytes MAC is added
to each scrambled trait esteem in Oracle 11g TDE (Transparent Database
Encryption) to guarantee information validness and on the database execution,
consequently inspiring numerous on-going exploration on that subjects. For
example, in the Database as a Service (DAS) connection, as MHT forces serious
simultaneousness imperatives that back off information upgrades, another mark
based verification technique has been presented as of late, to check the legitimacy,
fulfillment and freshness of question answers. What's more, some probabilistic
methodologies are additionally used to give uprightness certification to outsourced
database.
NAYAK 9
Work Cited
1. Hacigümüs H., Iyer B., Li C., Mehrotra S., Providing Database as a Service, International Conference on Data Engineering (ICDE), 2002, pp. 29-39.
2. Rakesh Agrawal , Jerry Kiernan , Ramakrishnan Srikant , Yirong Xu, Hippocratic
databases, Proceedings of the 28th international conference on Very Large Data
Bases, 2002, pp.143-154.
3. Ernesto Damiani, S. De Capitani Vimercati, Sushil Jajodia, Stefano Paraboschi,
and Pierangela Samarati, Balancing confidentiality and efficiency in untrusted relational dbms, Proceedings of the 10th ACM conference on Computer and communications security, ACM, 2003, pp. 93-102.
4.
Luc Bouganim and Philippe Pucheral, Chip-secured data access: confidential
data on untrusted servers, Proceedings of the 28th international conference on
Very Large Data Bases. 2002, pp. 131-142.
5.
IBM corporation, IBM Database Encryption Expert: Securing data in DB2, 2007.
6. Min Xie, Haixun Wang, Jian Yin, and Xiaofeng Meng, Integrity auditing of outsourced data, Proceedings of the 33rd international conference on Very large data
bases, 2007, pp. 782-793.