Database Reference
In-Depth Information
Extensibility/Adaptability:
Initially, the embedded watermark contains information such
as source provenance. However, in future there may be requirements for additional in-
formation regarding provenance or other issues. With our approach, the extension of the
embedded watermark information is no problem. If we intend to embed additional in-
formation in our watermark message, the (watermark) system is easy to adapt so that
the watermark contains the required information. We only have to take care that the wa-
termark still fits into the original image data.
5.2
Disadvantages
Effort for infrastructure:
As already mentioned, we need a holistic security infrastruc-
ture including a predefined tool chain to make our approach work. This, in turn, implies
a high effort to establish such infrastructure and as a result, leads to a proprietary, over-
all system. However, because of the high sensitivity of the managed data such a closed
system is inevitable from our point of view.
Residual risk:
There exists a residual risk of circumventing the reliable provenance
system. For instance, the keys for watermark generation may get lost. As a result, an
unauthorised user can create data with valid watermarks and insert them into FiVe DB.
Additionally, the proposed architecture also inherits some residual risks. For instance,
an attacker could maliciously change the UDF definitions if he gets the password of
the defining user or identify some weaknesses in Postgres itself (or the administration
of the DBMS). Consequently, we intend to integrate the watermarking process into the
DBMS itself, so that a DB user cannot change this behavior.
Insert and Update Performance:
As we mentioned, we intend to update the watermark
after each transformation. Since the update of the watermark includes its detection and
(re-)insertion it may lead to a decrease of the performance overall system. Since this is
not useful, we must find countermeasures to mitigate this effect. One possibility could
be that result computation and update provenance information are performed in an asyn-
chronous manner. For instance, the result could be computed and presented prior to the
update of the provenance information.
6
Related Work
Data Provenance is an active field of research. With respect to databases, different ap-
proaches for data provenance exist such as annotation or inversion [3,5,10]. However,
all approaches are applicable to (semi)-structured data only and beyond that, do not
consider the reliability of provenance information. In other domains such as service-
oriented architectures, research is already focused on reliability of provenance informa-
tion [29]. However, the proposed concepts are often tailored to the specific domain and
thus different to our approach and not applicable to the database domain.
Furthermore, a huge amount of research has been done in watermarking. For
databases, different approaches have been presented, that differ in the underlying data
types, subject to watermarking [1,24]. Furthermore, Sion proposes to use DB water-
marking for copyright protection [25]. However, all approaches have in common that
