3.2.1 Protection Objects
While the main objective of data protection systems is to ensure the confidentiality and integrity of disseminated data, we must also consider the following other information objects involved in the primary protection process and requiring protection:
• Metadata: Data is usually associated with descriptive information that can be used by both data re-cipients and by policy decision points when making authorisation decisions. Integrity of the associated metadata needs to be guaranteed as compromised metadata can greatly affect the decision process. For example, if metadata contained the ID of the object’s owner and this were modified, a possibly unau-thorised subject could get access to the data. Moreover, in many scenarios metadata may be considered confidential as it can reveal information on the data content.
• Policies: Policy integrity must be guaranteed to ensure correct authorisation decisions are taken for every request. Policies can also be considered confidential as they may contain the identity of users authorised to access the data or may be used to obtain the needed credentials in non-legal ways.
• Credentials: As for metadata and policies, integrity of credentials used in the policy evaluation process must be guaranteed. While we deem the use of digital signatures in traditional certification standards (e.g. X.509) sufficient to verify credentials’ integrity, we consider a different problem. Users’ identity and attribute credentials may in fact be considered private and should thus be protected when being sent from a data recipient (or credential provider) to a trusted policy decision point.
3.2.2 Adversary
The overall trust model considered in this thesis is that of a trusted data originator who needs help in protecting her resources, but also of a potentially malicious recipient - i.e. a user that, after data reception, might try to use it in violation of the originator’s policies. Our solution is thus aimed at proposing a non-circumventable information security mechanism that data originators can rely on when disseminating data amongst unknown and potentially malicious recipients. These include malicious users in honest organisations (i.e. organisations participating in a DSA), curious but not malicious users that can attempt to stray from the intended data usages if the opportunity arises, and malicious unknown users (i.e. users that do not belong to any organisation par-ticipating in a DSA). We do not consider the case of a malicious organisation agreeing and parpar-ticipating in a DSA, as most of the time decisions on the amount of trust that can be put on high-level organisations rely on controls put in place by traditional legislative systems or on the reputation, brands and ongoing relationships of the involved entities.
Besides malicious users, when dealing with changing data we must also consider the case of honest but incompetent recipients, i.e. recipients who can access the data and modify it, but that cannot be trusted to perform correct modifications or to specify correctly what policies the new data should be associated with.
This is a particularly important aspect, as many of the security attacks nowadays mainly exploit users’ mistakes or na¨ıvety or conversely the provision of unusable security systems. A wrongly specified policy can cause a data leakage as much as a weak password or a weak cryptographic key. Also, while we do not consider malicious data originators, we must consider honest but curious data originators, i.e. originators who attempt to learn potentially private details on users by disseminating protected data and forcing recipients to provide their credentials for policy evaluation.
Note that this adversary model is asymmetric, as it does not consider malicious organisations falsely accusing data recipients of misusing disseminated data. This aspect of the mutual relationships between data originators and recipients is outside the scope of this thesis.
Threats
Figure 3.1: Attack tree for data protection architecture. Shaded attacks are dealt with by mainstream products.
Non-shaded attacks are dealt with natively by our proposed architecture
3.2.3 Threats
Figure 3.1 depicts the indicative set of threats we considered when designing our architecture, where we con-sider as threats all the attacks on the protection system that users can perform to obtain unauthorised access to data. These were chosen as the most likely attacks used nowadays by users trying to compromise existing DRM and ERM systems or to gain information they would normally have no access to. Malicious users can attack data protection systems by either trying to compromise the authentication process, the policy decision process, the enforcement process or the system’s availability. We emphasise that in this thesis we do not deal with threats that aim to attack human vulnerabilities of an organisation rather than its information system such as bribery of employees, industrial espionage etc. Such threats must still be dealt with to guarantee data con-fidentiality, integrity and availability through the provision of a safe operational envelope comprising physical controls, human training and best usage practices within which the automatic protection tools can operate.
Attacks that try to compromise the authentication process (e.g. credential forging, collusion, IP spoofing etc) have been the focus of intensive research and we will not deal with them in this thesis. A different attack we consider instead comprises curious data originators trying to learn private details on data recipients when eval-uating their access requests. This can be achieved by disseminating protected data whose publishing server (in the case of Microsoft RMS, described in Section 2.5.2) or policy evaluation authority is under the originator’s control and can thus disclose the content of the received credentials.
The policy decision process can be compromised by either modifying the policies or the metadata needed during the evaluation. In both cases, the attack type depends on how policies and metadata are stored. If
policies and metadata are stored on a server, the attack can be performed by compromising the communication between the server and the data originator at publishing time (e.g. with man-in-the-middle attacks, substitution attacks etc.), or by attacking the policy and metadata store directly. Otherwise, if the policies and metadata have been attached to the data and are disseminated along with it, the attacker can try to modify them directly.
Many security protocols and cryptographic techniques have been proposed to both attach policies and metadata to data and to protect their integrity. However, since we propose a new data protection and policy decision protocol, we also described how the integrity of policies and metadata is protected.
The most common attack on the policy enforcement process is based on installing malicious software in the same environment where the PEP (see Section 2.4.1) or virtual machine run. Eventually, data must be streamed without protection to authorised recipients, to be either displayed on a video, played on speakers and so on.
During the streaming, malicious software can capture the streamed data and save it back with no protection.
Similarly, malicious software can try to read data decryption keys once they have been downloaded to access received data rightfully. Another attack consists in substituting critical software components in the enforcement architecture with malicious ones (that for example do not force the recipient to perform obligations, or do not enforce continuous controls on data accesses). In general, these attacks all deal with the inner vulnerabilities of a software environment over which malicious data recipients have complete control and in which policies must be enforced. While in traditional ERM systems deployed in corporate environments users have no control over the machines they use, which are rather controlled by a trusted administrator, we also consider the case of malicious data recipients acting outside of any trusted organisation and who thus maintain control over their own platforms. These users could install any malicious software beside the virtual machine needed to access data and thus bypass the data protection. Therefore, these untrusted software environments constitute a problem we must deal with. This is why a trusted computing platform is required to ascertain the integrity of the enforcement.
Availability can also be compromised by adversaries in a number of ways (e.g. denial-of-service attacks).
This traditional type of attacks have been extensively studied. Otherwise, availability could be compromised when users retain data and refuse to exchange it. Cryptographic protocols do not deal with Denial of Service attacks caused by retained or not exchanged messages, and we do not try to detect message loss as communi-cation protocols already deal with it. However, we must still deal with the case where data unavailability is not caused by external attacks, for example when remote components of the overall data protection system (such as publishing servers or credential providers) are not reachable because connectivity is not available. This is an intrinsic condition of the dissemination environment rather than the result of a malicious attack, but it is still a risk to the system’s operations.
Finally, we consider a particular set of attacks that can be performed when no control is enforced on data derivation. If a user is authorised to modify some data she received, she might introduce sensitive information that requires a higher level of protection than what the original policies provide. Similarly, a user may create new sensitive data and not associate it with any policy at all, or with insufficiently strict policies. She might even specify policies that do not allow anyone to access the disseminated data, thus making it useless. In other words, a wrong policy specification can lead to either data unavailability or to leakages of sensitive data. This is due to the discretional aspect of policy specification, whereas in corporate environments mandatory policies should also be specified at organisational level.