218
Barbara Carminati and Elena Ferrari
publishers may not be trusted, it is necessary to devise some mechanisms to avoid
their malicious use of owner’s data.
Authenticity and integrity. In general, ensuring data authenticity implies that users
are assured that the received data come from the intended source, whereas ensuring
data integrity means ensuring that data contents are not altered during their transmission from the source to the intended recipients.
1 Enforcing authenticity/integrity
requirements in outsource-based architectures implies assuring that a user receiving
some data from a publisher is able to verify that the data have been generated by
the owner and that the publisher has not modified their contents. In traditional architectures, a well-established approach to ensure both authenticity and integrity is
based on the use of digital signatures [27]. According to this solution, before sending data to users the owner digitally signs it. Applying such a solution to third-party
architectures implies that owners sign each document they send to publishers. However, this solution is not suitable for a third-party architecture in that a publisher may
return to users only selected portions of a document, depending on the query they
submit and/or on the access control policies in place. Thus, the user by having only
selected portions is not able to validate the owner’s digital signature, which has been
generated for the whole document. For this reason, there is the need to investigate
alternative ways to digitally sign a document, defined in such a way that they enable a user to validate the digital signature even if he/she has only received selected
portions of the signed document.
Completeness. Third-party architectures introduce a further novel security requirement, that is, completeness. Since answers to user’s queries are generated by possible
untrusted publishers, a further important requirement is that a user receiving an answer must be able to verify the completeness of the received data, that is, the user
must be able to verify that he/she receives all data answering the submitted query
and satisfying owner’s access control policies.
10.3 State of the Art
The most intuitive solution for secure outsourcing is to require publishers to be
trusted with respect to the considered security requirements. However, as we discussed in the previous section, this solution may not always be feasible in the Web environment, since large Web-based systems cannot easily be verified to be secure and
can easily be penetrated. For this reason, there is a strong need to devise strategies to
ensure security properties in third-party architectures, even in the presence of an untrusted publisher. These issues have been investigated by different research groups,
with several resulting proposals for the different security requirements. In this section, we survey the main results proposed so far, by grouping them according to the
security requirements they address and the data model for which they are proposed.
Table 10.1 summarizes, for each security requirement, the solutions discussed.
1 Here we do not consider integrity with respect to the specified access control policies, since
third-party architectures are mainly conceived for read accesses.
Barbara Carminati and Elena Ferrari
publishers may not be trusted, it is necessary to devise some mechanisms to avoid
their malicious use of owner’s data.
Authenticity and integrity. In general, ensuring data authenticity implies that users
are assured that the received data come from the intended source, whereas ensuring
data integrity means ensuring that data contents are not altered during their transmission from the source to the intended recipients.
1 Enforcing authenticity/integrity
requirements in outsource-based architectures implies assuring that a user receiving
some data from a publisher is able to verify that the data have been generated by
the owner and that the publisher has not modified their contents. In traditional architectures, a well-established approach to ensure both authenticity and integrity is
based on the use of digital signatures [27]. According to this solution, before sending data to users the owner digitally signs it. Applying such a solution to third-party
architectures implies that owners sign each document they send to publishers. However, this solution is not suitable for a third-party architecture in that a publisher may
return to users only selected portions of a document, depending on the query they
submit and/or on the access control policies in place. Thus, the user by having only
selected portions is not able to validate the owner’s digital signature, which has been
generated for the whole document. For this reason, there is the need to investigate
alternative ways to digitally sign a document, defined in such a way that they enable a user to validate the digital signature even if he/she has only received selected
portions of the signed document.
Completeness. Third-party architectures introduce a further novel security requirement, that is, completeness. Since answers to user’s queries are generated by possible
untrusted publishers, a further important requirement is that a user receiving an answer must be able to verify the completeness of the received data, that is, the user
must be able to verify that he/she receives all data answering the submitted query
and satisfying owner’s access control policies.
10.3 State of the Art
The most intuitive solution for secure outsourcing is to require publishers to be
trusted with respect to the considered security requirements. However, as we discussed in the previous section, this solution may not always be feasible in the Web environment, since large Web-based systems cannot easily be verified to be secure and
can easily be penetrated. For this reason, there is a strong need to devise strategies to
ensure security properties in third-party architectures, even in the presence of an untrusted publisher. These issues have been investigated by different research groups,
with several resulting proposals for the different security requirements. In this section, we survey the main results proposed so far, by grouping them according to the
security requirements they address and the data model for which they are proposed.
Table 10.1 summarizes, for each security requirement, the solutions discussed.
1 Here we do not consider integrity with respect to the specified access control policies, since
third-party architectures are mainly conceived for read accesses.