Databases Reference
In-Depth Information
There are 3 basic models of trust that are widely studied in literature. The first
model is that of “complete trust” where the server-side is completely trusted
by the client to implement the required functionalities (e.g., query execution)
and has complete faith on its security measures. In this scenario encryption
might not be required at all and therefore, the data management issues are
quite similar to those arising in standard DBMS systems. The second sce-
nario is that of “partial trust”, where though the service-provider is trusted
to implement functionalities correctly, the sensitive information might be ac-
cessible to some adversary in the following two scenarios: (i) Some server-side
entities (e.g., administrators) who may have the authority to access the data,
but cannot be trusted completely to maintain confidentiality. (ii) The security
measures on the server-side (e.g., network security) cannot be guaranteed to
be completely safe from unauthorized access by outside hackers. In both these
scenarios, the goal is to ensure the confidentiality of sensitive data by prevent-
ing its misuse by either legitimate or unauthorized users. The third model of
trust is where the server is not trusted to even implement all functionalities
correctly (truthfully). We refer to this as the “untrusted model”. In this case
additional steps need to be taken by the client to ensure authenticity of data
and correctness of query results.
We start by discussing some of the issues that need to be considered while
selecting the encryption function, especially with respect to relational data.
Then, we summarize the techniques proposed in literature for integrity and
authentication for the untrusted server model.
3.1 Encrypting relational data
The appropriate encryption algorithm to support in a relational database sys-
tem is decided based on its performance characteristics. An important factor
that dictates the performance is the data granularity at which encryption is
supported. In a typical RDBMS, the encryption granularity could be at the
field, the row or the page level. Authors in [22] report that embedding encryp-
tion within relational databases entails a significant startup cost. Row/page
level encryption amortize this cost over larger data and therefore are more
preferable than field-level encryption in general. Another criteria to consider
while choosing the encryption algorithm is software versus hardware level en-
cryption. Whereas software level encryption allows more flexibility in terms
of algorithm selection and granularity control, hardware-based solutions are
much faster, but can support only a small set of algorithms, like DES [15] and
AES [2]. Therefore depending upon the application and trust model, a choice
has to be made whether to use hardware or software level encryption. Au-
thors in [26] experimentally determine that a row-level symmetric key based
encryption scheme offers the best tradeoff between performance and object
granularity. In general, the 3 important issues to keep in mind are (1) How
fast is the encryption function, is it implementable at the hardware level; (2)
how to perform key management; (3) at what granularity to encrypt data.
