Legal FAQ on Multi-Party Computation

1.1. Is there any particular EU harmonization on liability in the context of the sharing of data to MPC protocols?

There exists no specific liability regime concerning the concrete scenario of data sharing using MPC protocol. Therefore, reference ought to be made to the general liability regimes in the EU, as well as domestic tort laws.

Q.1.2. Is there any general EU harmonization on liability, which may be applicable in this context?

Firstly, it ought to be stated that the liability regime within the EU is mostly non-harmonized, with the exclusion of i.a.:

• product liability law under Directive 85/374/EC;
• certain aspects of liability for infringing data protection law (Art. 82 of the General Data Protection Regulation (GDPR);
• liability for breaching competition law (Directive 2014/104/EU);
• liability insurance concerning damage caused by the use of motor vehicles (Directive 2009/103/EC); and
• conflict of tort laws, in the veil of the Rome II Regulation.
• Sectoral Legislations (i.e. EU consumer protection framework)

Given that this question does not relate to concerns of data protection or competition law, the only potentially applicable regime concerns the product liability directive. The question then arises whether data could be regarded as a product under Directive 85/374/EC. If this is the case, our answer will be embedded in the harmonized liability regime innate to this Directive. Unfortunately, specialized literature chiefly rejects such an interpretation. Hence, based upon both the materially limited notion of ‘product’ under the Directive, as well as on internal Safe-DEED research, it seems that Directive 85/374/EC shall not be applicable in establishing the liability regime in this case scenario.

To conclude it is possible to affirm there exists no harmonized liability regime concerning damage stemming from the provision of incorrect plain text to an MPC protocol.

Q1.3. Are there any domestic liability rules that could be applied to the MPC case scenario?

The existing domestic liability regimes may not always be unequivocally applied mutatis mutandis to the MPC context. In other words, these rules may not always plainly fit the very nature of MPC protocols; nor may they be adapted to new technologies in general. In conclusion, due to the substantial divergences between the liability regimes of all member states, the outcome of cases will often be different depending on which jurisdiction applies.

Q1.4. Which are the most common forms of liability in domestic laws applicable to this use case

Despite these substantial differences between the liability regimes in EU member states, most states’ fault-based regimens are generally rooted in the same criteria (most commonly distinguished as ‘fault’, ‘damage’, and ‘causal relation’). Our concrete case scenario relates to the ‘fault’-criterion (“would committed the wrongful act?”).

Fault-based liability

Most EU domestic laws share the same legal conception of ‘fault’ under their respective liability laws. To establish ‘fault’, two aspects should be determined: (I) it ought to be identified that the duties of care of the perpetrator have been discharged, and (II) it should be proven that the conduct of the perpetrator of the damage did not discharge those duties as stressed by H Koziol.

The duties at issue are determined by a plethora of (non-)legal factors. Occasionally, they are defined beforehand by statutory language prescribing or prohibiting certain specific conduct. Still, often they must be reconstructed after the fact by the court based on social beliefs about the prudent and reasonable course of action in the circumstances (i.e. the principle of good neighbourliness, or bonus pater familias). In other words: can it be expected – from an average and reasonable data provider in similar circumstances – that he or she would share correct data? If the answer to this question is affirmative, it could be argued that the data provider has committed wrongful conduct on this occasion. If it can then subsequently be established that the data user’s (economic) damage can be causally attributed to this wrongful conduct, the data provider can be held liable for these damages.

This entire question rests on what can be expected from an average and reasonable data provider in similar circumstances. Suppose the nature of the data is f.i. too technical to be properly understood and correctly shared by the average, suitable data provider, would be difficult to attribute them the liability. Consequently, we should question what can be expected from an average, reasonable data provider whilst providing data to an MPC protocol. These sorts of questions usually depend on the court’s interpretations and their respective balancing exercise. Given the non-existence of relevant case law, it seems necessary regulators need to focus on filling this gap in ascertaining liability in these complex contexts.

• Strict liability (i.e. non-fault based liability)

When it comes to strict liability occurs when the action put in place is intended generate a tort. Consequently, The claimant need only prove that the tort occurred and that the defendant was responsible.Notwithstanding overall understanding across the EU, its precise conditions strongly differ depending on the Member State, though its conditions are generally more restrictive than a fault-based liability . Moreover, it seems unlikely that strict liability would be accepted in the scenario of data trading, as the potentiality of being held liable without fault would undeniably frighten data providers from sharing their data, and would thus hamper the advancement of data marketplaces.

• Vicarious liability

Vicarious liability is a situation in which one party is held partly responsible for the unlawful actions of a third party. The third party also carries his or her own share of the liability. Vicarious liability typically arises in situations where one party is supposed to be responsible for (and have control over) the third party. It is correspondingly negligent in carrying out that responsibility and exercising that control. Nonetheless, in this MPC scenario, no such relationship or responsibility seems to be at play whatsoever. Hence, it seems highly unlikely that this third form of liability would apply to our case scenario.

A1

It can be concluded that there is not a harmonized regulation that deals with the liability occurring in an MPC scenario. Therefore, it is necessary to refer to the domestic laws of the EU Member States. Similarly, also at a national level, a liability regime tailored on MPC protocols has not been developed yet. Thus, the precise liability when providing data to an MPC protocol is still somewhat unclear de lege lata. Still, it is possible to list down general considerations on liability regimes.

Generally, in the EU domestic liability regimes, a differentiation is made between fault-based, strict and vicarious liability.

The allocation of liability generally relies on two factors:

1) the particular domestic law that applies – which depends on the facts of the case; and

2) what can be expected from an average, reasonable data provider (bonus pater familias) in similar circumstances – which strongly depends on what courts consider the norm in each scenario.

A2

The question on who is liable (data provider or user) whilst running a decentralized MPC protocol, generally depends on what is meant with ‘when things go wrong’. Usually, the parties’ potential respective liabilities can be ascertained by answering the following steps:

• If the damage can be attributed to one of the parties (i.e. the data provider OR the data user), and this party did not behave in line with the bonus pater familias criterion, then this party has committed a misconduct or fault. If this misconduct can then be established to have causally resulted in damage pursuant to the applicable domestic laws, then this party can be held liable.
• If no misconduct can be attributed to neither (or one) party, then no liability can be concluded for the ensuing damage unless there is a form of strict liability under the domestic law that applies in the concrete case scenario.
• If a fault can be attributed to both parties, then both can be held liable if the respective applicable laws recognize joint liability (both data provider and user are fully liable for all damage) or several liability (the parties are merely liable for their respective proportionate obligations – if unclear: judge determines both parties’ obligation and the corresponding liability).

The perceived trustworthiness of MPC chiefly depends on the perceived transparency and perceived coherence of such a protocol. Both transparency and perceived coherence mainly rely upon respectively the MPC applications’ transparency on data protection, and the coherence regarding the intent of the application. Nonetheless, transparency and coherence merely add to perceived trustworthiness.

For an MPC cryptographic protocol to be considered trustworthy, these transparency and coherence guarantees ought to have legal value, so that any false claims can be legally challenged. Consequently, it is necessary to focalize on the EU privacy and data protection framework since it embeds the two principles. In Art.5 GDPR, the EU legislator has listed both transparency and coherence (of the processing- purpose limitation) as crucial principles of the EU privacy and data protection framework. The compliance of an MPC protocol with both principles of transparency and purpose limitation needs to be verified throughout a tailored assessment on the implications such protocols have for data subjects.

In the MPC context, such assessment has to mainly focus on the nature of encrypted data (personal vs non-personal) and consequent applicable legal regime depends; in other words, on whether or not such data can be related and identify a natural person. In fact, according to Art. 4.1 GDPR defines ‘personal data’ and stipulates its core elements, being: (I) any information, (II) relating to, (III) identified or identifiable, and (IV) a natural person. The first and last elements do not seem to be controversial in the MPC context, while the others require additional considerations. Given that the ‘related to’ element is generally accepted as being broad and encompassing all (in)direct references to a natural person, encryption does not seem to hinder this element. The identifiability criterion seems slightly more disputable. Along the years, the EU data protection regulators and the European Court of Justice have both tried to substantiate further the notion of ‘identifiable’ under the GDPR.

If the MPC protocol meets specific criteria listed both by the Court of Justice and the EU data protection regulators data-set containing personal data cannot be identified by entities other than the one in possession of the encryption key. Still, such an activity, determining the anonymization of personal data through the use of encryption protocols, falls into the definition of ‘processing (of personal data)’ of the GDPR and, thus, needs to comply with EU privacy and data protection framework. Consequently, encrypted data can be classified anonymous only after (and not yet during) they have been fully encrypted. Consequently, only those the entities processing anonymous and non-identifiable data will not have to comply with legal and ethical requirements stemming from such a framework. The others, involved in such a process will always have to ensure the respect of privacy and data protection principles, consequently providing the necessary safeguards for the data subjects. Doing so, such protocols, once the respect of certain technical criteria is secured, can be fairly defined trustworthy.

A3

The level of transparency and coherence are usually regarded as indicators of trustworthiness. Nonetheless, this merely concerns perceived trustworthiness, and might – albeit being an initial indicator – not be a guarantee of a protocol’s actual trustworthiness. Therefore, one may opt to consult the trustworthiness of the protocol running an MPC. The encryption process of personal data can be classified as the processing of personal data under Art. 4 GDPR. Hence, the institutions backing the encryption are under a legal obligation to adhere to the transparency and data protection obligations in the GDPR. Consequently, in case of a lack of transparency or apparent trustworthiness, data subjects may make use of the legal remedies foreseen in the GDPR (Art.77-82).

A4

In order to assess whether the MPC protocol is indeed not sharing my raw personal data, as data subject, I can rely upon my right to transparent information, embedded in GDPR. Moreover, if I believe my data has not been properly encrypted, I can ultimately rely on the remedies foreseen in the GDPR such as the right to lodge a complaint with a supervisory authority, or the right to an effective judicial remedy against a controller or processor.

This question relates to the case where the data user runs the algorithm so many times that the data provider’s input can be guessed. In other words: the data now is identifiable again and therefore can be regarded as ‘personal’.

A5

From a legal-technical standpoint, the argument can then be made that the body backing the MPC algorithm (i.e. the data processor) has not been able to sufficiently guarantee its security obligation pursuant to Art. 32 GDPR and Rec. 83.

Moreover, it could be argued that the entity managing the processing activity of personal data through MPC (the data controller) has not met his ‘lawfulness of processing’ obligation. If this processing is carried out with the sole aim of ultimately identifying the input of the data subject, then the (now) personal data have been obtained in violation of the GDPR principles and consequently not ensuring data subjects’ rights.

Nonetheless, it should be stated that the first safeguard only holds true if it can demonstrate that the data processor could have done more to ensure the security of personal data. If the MPC algorithm functioned according to expectation and the processor could not have known of any further risks, then this safeguard can hardly be applied. Moreover, the second safeguard vis-à-vis the data controller can only be put forward if the data market peer intentionally processed the data to identify the data provider’s input. Any ‘accidental’ discoveries in this regard do not seem to be sufficiently grave to trigger the data user’s failed responsibility under Art. 6(4)e GDPR. Still, the data provider can enforce these two safeguards by relying upon the remedies in chapter VIII GDPR.

The wording “safe to use from a legal perspective” is rather broad. Hence, it seems that this question comprises two consequent issues:

Q6.1. Does MPC respect the data providers’ fundamental rights?

Whether or not an cryptographic technique is “safe to use from a legal perspective” relies upon its ability to protect the data provider’s fundamental rights. These are most commonly grounded in several fundamental rights protection schemes, most predominantly consisting of the United Nations Universal Declaration of Human Rights, the European Convention of Human Rights and the Charter of Fundamental Rights of the European Union. Still, a mere focus on fundamental rights protection does have its innate shortcomings.

A6.1.1

The use of MPC, if meeting certain technical and legal requirements might represent “a fair measure” to balance on the one hand fundamental rights of data owners and the other legitimate business expectations of those entities involved in the data-markets’ activities. MPC namely does not merely guarantee the protection of these rights vis-à-vis adversaries, but with regard to other participants to the algorithm as well, making it especially adequate in the data marketplace context.

Q6.2. Can this adherence to fundamental rights be legally guaranteed?

The MPC is a rather secure cryptography technique with an eye on fundamental rights protection. Nonetheless, the answer to this question is twofold: it should first be considered whether the data shared using an MPC protocol can be deemed ‘personal data’ under the GDPR, as well as whether this activity can be classified as the ‘processing’ thereof (idem. Art. 2.1 GDPR). To do so, it is necessary to assess the nature of data processed and whether or not data available to parties other than the data controller can fall into the definition of personal data.

A6.2.2

According to Art. 4.1 GDPR defines ‘personal data’ and stipulates its core elements, being: (I) any information, (II) relating to, (III) identified or identifiable, and (IV) a natural person. When such criteria have met the encryption of data using an MPC protocol could be classified as the processing of personal data under Art. 4 GDPR. Hence, data providers are protected under the umbrella of the GDPR. In the event also data available to other data market peers fall into the definition of personal data, we will have a joint controllership, with shared responsibilities among those entities in charge of the processing activities. Consequently, in case an MPC application is backed by an institution that does not adequately provide or respect the privacy and data protection principles, the data subject may subsequently rely on the complaints and judicial remedies laid down in GDPR. This is a thus a legal backbone to ensure the respect of an MPC protocol for the fundamental rights of the data owner.

A6

This question can be interpreted in two interlinked ways. Firstly, the question is whether an MPC algorithm can be applied in line with the respect for the fundamental rights of the data owner. On a subsequent level, it could be questioned whether there exist any legal guarantees to this adherence to data owners’ fundamental rights.

Both sub-questions have been answered in the affirmative. In fact, concerning the right to data protection, an MPC that meets the technical criteria developed by the European Court of Justice and the EU body of data protection regulators, ensure respects the GDPR guiding principles and provide data subjects with necessary remedies.

The EU Cybersecurity Act Regulation (hereafter ‘EU Cybersecurity Act’) foresees the implementation of an EU cybersecurity certification scheme for ICT products, ICT services, and ICT processes. This Act entered into force in June 2019 and was established under the mandate of the European Union Agency for Cybersecurity (ENISA). In light of the large diversity and many uses of ICT products, services and processes – the European Cybersecurity Certification framework enables the creation of tailored and risk-based EU certification schemes. In particular, each European scheme should specify: a) the categories of products and services covered, b) the cybersecurity requirements, for example by reference to standards or technical specifications, c) the type of evaluation (e.g. self-assessment or third party evaluation), and d) the intended level of assurance (e.g. basic, substantial and/or high).

At this point in time, however, there is not yet any explicit clarification as to whether the implementation of MPC encryption will fall within the ambit of the certification process innate to the EU Cybersecurity Act. Nonetheless, there are two indications that MPC encryption indeed falls within the material scope of application of the Regulation:

1. The Regulation applies to the certification of ‘ICT-services’. Under the autonomous definition, these include all services consisting fully or mainly in the transmission, storing, retrieving or processing of information by means of network and information systems. As has been expanded upon in the previous answer, it has been widely accepted that the encryption of personal data does fall within the scope of ‘processing of information’. Subsequently, it can hardly be contested that MPC encryption falls within the scope of application of the Regulation.
2. Rec. 40 of the Cybersecurity Act explicitly mentions that the promotion of basic multi-factor authentication – such as encryption – is part of ENISA’s goals.

A7

Momentarily, it seems that the EU Cybersecurity Act does provide a legal basis for the certification of MPC encryption, which seems to have been confirmed by ENISA in its latest report. However, any further arrangements (on certification requirements, evaluation,…) regarding the certification schemes mainly rests on the ECCG, which has not explicitly reported on the certification of MPC encryption as of yet.

Data are nowadays considered precious production factors. When it comes to data, there is a strong link between the power of use and transfer of data on the one hand, and the economic value associated with such data on the other hand. Consequently, the possibility to transfer data is linked to the possibility to confer commercial use of such data or data sets, without necessarily having the exclusive property right. Notwithstanding such a context, there are additional considerations we should do if the transfer interest personal data. Privacy and data protection law, in fact, do not foresee a comprehensive transfer of right to use. Data subjects always maintain certain rights over their data since this would go against the fundamental rights of the data subject, and ethical principles linked to such data.

Whether or not personal or encrypted data can be evaluated depends on what is being understood under ‘evaluation’. Notwithstanding the necessity to understand the monetary value of data, scholars, policymakers, and interested businesses should also consider other matters. All actors and entities providing and processing personal data assign them a specific value. Such value might be economic, ethical, normative and societal. In a scenario where consumers and businesses interact with each other, we should primarily assess first of all, which are the characteristics of such a relationship and subsequently, which are the values that lead such interactions. The main reason that underlines the interaction and exchange of personal data between data subjects and business is represented by the reciprocal benefits they gain from such exchange. While business motivations are strictly economic, the data owner motivations can be economical (i.e. personalized service), but also psychological (reduced time to find goods or services that might meet our interest).

A8

Encryption does play a valuable role in preserving confidentiality and fundamental rights that embeds all listed values. The use of MPC protocol in particular, first of all, guarantee a substantial reduction of risks linked to the processing of personal data as requested by the GDPR. To achieve such purpose, compliance of such cryptographic measures with the EU framework will be ensured following the measurable criteria listed by the European Court of justice and EU body of national data protection regulators. In concrete MPC likewise, other cryptographic measures should ensure the extreme difficulty (in terms of economic and personal effort) for third parties to identify data subjects from the available information.  Concretely, the identification process should require third parties a disproportionate effort in terms of time, cost and workforce applicable to the whole data process. To conclude, the use of MPC will support activities of parties involved in data processing activities in complying with the EU law, respect fundamental rights and individual ethical values, with a consequent overall positive outcome for society.