Page 1
Pseudonymisation techniques and best practices Recommendations on shaping technology according to data protection and privacy provisions NOVEMBER 2019 0
Page 2
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 ABOUT ENISA The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross- border communities committed to improving network and information security throughout the EU. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu CONTACT For contacting the authors please use isdp@enisa.europa.eu For media enquiries about this paper, please use press@enisa.europa.eu CONTRIBUTORS Meiko Jensen (Kiel University), Cedric Lauradoux (INRIA), Konstantinos Limniotis (HDPA) EDITORS Athena Bourka (ENISA), Prokopios Drogkaris (ENISA), Ioannis Agrafiotis (ENISA) ACKNOWLEDGEMENTS We would like to thank Giuseppe D'Acquisto (Garante), Nils Gruschka (University of Oslo) and Simone Fischer-Hübner (Karlstad University) for reviewing this report and providing valuable comments. LEGAL NOTICE Notice must be taken that this publication represents the views and interpretations of ENISA, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the Regulation (EU) No 2019/881. This publication does not necessarily represent state-of the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. COPYRIGHT NOTICE © European Union Agency for Cybersecurity (ENISA), 2019 Reproduction is authorised provided the source is acknowledged. For any use or reproduction of photos or other material that is not under the ENISA copyright, permission must be sought directly from the copyright holders. ISBN 978-92-9204-307-0, DOI 10.2824/247711 1
Page 3
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 TABLE OF CONTENTS 1. INTRODUCTION 7 1.1 BACKGROUND 7 1.2 SCOPE AND OBJECTIVES 7 1.3 OUTLINE 8 2. TERMINOLOGY 9 3. PSEUDONYMISATION SCENARIOS 11 3.1 SCENARIO 1: PSEUDONYMISATION FOR INTERNAL USE 11 3.2 SCENARIO 2: PROCESSOR INVOLVED IN PSEUDONYMISATION 12 3.3 SCENARIO 3: SENDING PSEUDONYMISED DATA TO A PROCESSOR 12 3.4 SCENARIO 4: PROCESSOR AS PSEUDONYMISATION ENTITY 13 3.5 SCENARIO 5: THIRD PARTY AS PSEUDONYMISATION ENTITY 14 3.6 SCENARIO 6: DATA SUBJECT AS PSEUDONYMISATION ENTITY 14 4. ADVERSARY MODEL 16 4.1 INSIDER ADVERSARIES 16 4.2 EXTERNAL ADVERSARIES 16 4.3 GOALS OF ATTACK ON PSEUDONYMISATION 17 4.3.1 Pseudonymisation secret 17 4.3.2 Complete re-identification 17 4.3.3 Discrimination 17 4.4 MAIN ATTACKING TECHNIQUES 18 4.4.1 Brute force attack 18 4.4.2 Dictionary search 19 4.4.3 Guesswork 19 4.5 UTILITY AND DATA PROTECTION 20 5. PSEUDONYMISATION TECHNIQUES 21 5.1 SINGLE IDENTIFER PSEUDONYMISATION 21 2
Page 4
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 5.1.1 Counter 21 5.1.2 Random number generator (RNG) 21 5.1.3 Cryptographic hash function 22 5.1.4 Message authentication code (MAC) 22 5.1.5 Encryption 22 5.2 PSEUDONYMISATION POLICIES 23 5.2.1 Deterministic pseudonymisation 23 5.2.2 Document-randomized pseudonymisation 23 5.2.3 Fully-randomized pseudonymisation 24 5.3 CHOOSING A PSEUDONYMISATION TECHNIQUE AND POLICY 24 5.4 RECOVERY 25 5.5 PROTECTION OF THE PSEUDONYMISATION SECRET 25 5.6 ADVANCED PSEUDONYMISATION TECHNIQUES 25 6. IP ADDRESS PSEUDONYMISATION 27 6.1 PSEUDONYMISATION AND DATA PROTECTION LEVEL 27 6.2 PSEUDONYMISATION AND UTILITY LEVEL 28 6.2.1 Pseudonymisation level 28 6.2.2 Choice of pseudonymisation mode 29 7. EMAIL ADDRESS PSEUDONYMISATION 31 7.1 COUNTER AND RANDOM NUMBER GENERATOR 31 7.2 CRYPTOGRAPHIC HASH FUNCTION 33 7.3 MESSAGE AUTHENTICATION CODE 33 7.4 ENCRYPTION 34 8. PSEUDONYMISATION IN PRACTICE: A MORE COMPLEX SCENARIO 36 8.1 A MOCK-UP EXAMPLE 36 8.2 DATA-INHERENT INFORMATION 37 8.3 LINKED DATA 37 8.4 MATCHING DISTRIBUTION OF OCCURRENCES 38 8.5 ADDITIONAL KNOWLEDGE 38 8.6 LINKAGE AMONG MULTIPLE DATA SOURCES 39 8.7 COUNTERMEASURES 40 3
Page 5
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 9. CONCLUSIONS AND RECOMMENDATIONS 42 REFERENCES 44 4
Page 6
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 EXECUTIVE SUMMARY In the light of the General Data Protection Regulation (GDPR)1, the challenge of proper application of pseudonymisation to personal data is gradually becoming a highly debated topic in many different communities, ranging from research and academia to justice and law enforcement and to compliance management in several organisations in Europe. Based on previous ENISA’s work in the field2, this report explores further the basic notions of pseudonymisation, as well as technical solutions that can support implementation in practice. In particular, starting from a number of pseudonymisation scenarios, the report defines first the main actors that can be involved in the process of pseudonymisation along with their possible roles. It then analyses the different adversarial models and attacking techniques against pseudonymisation, such as brute force attack, dictionary search and guesswork. Moreover, it presents the main pseudonymisation techniques (e.g. counter, random number generator, cryptographic hash function, message authentication code and encryption) and pseudonymisation policies (e.g. deterministic, document-randomized and fully randomized pseudonymisation) available today. It especially addresses the parameters that may influence the choice of pseudonymisation technique or policy in practice, such as data protection, utility, scalability and recovery. Some more advanced pseudonymisation techniques are also briefly referenced. On the basis of the aforementioned descriptions, the report further builds on two use cases on the pseudonymisation of IP addresses and email addresses, analysing the particularities arising from these specific types of identifiers. It also examines a more complex use case of the pseudonymisation of multiple data records, discussing the possibilities of re- identification. One of the main outcomes of the report is that there is no single easy solution to pseudonymisation that works for all approaches in all possible scenarios. On the contrary, it requires a high level of competence in order to apply a robust pseudonymisation process, possibly reducing the threat of discrimination or re-identification attacks, while maintaining the degree of utility necessary for the processing of the pseudonymised data. To this end, the report draws the following conclusions and recommendations for all relevant stakeholders as regards the practical adoption and implementation of data pseudonymisation. A RISK-BASED APPROACH TOWARDS PSEUDONYMISATION Although all known pseudonymisation techniques have their own, well-understood, intrinsic properties, this does not render the choice of the proper technique a trivial task in practice. A risk-based approach needs, thus, to be adopted, assessing the required protection level, while considering relevant utility and scalability needs. Data controllers and processors should carefully consider the implementation of pseudonymisation following a risk-based approach, taking into account the purpose and 1 Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), https://eur-lex.europa.eu/legal- content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN 2 ENISA, Recommendations on shaping technology according to GDPR provisions: an overview on data pseudonymisation, https://www.enisa.europa.eu/publications/recommendations-on-shaping-technology-according-to-gdpr-provisions 5
Page 7
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 overall context of the personal data processing, as well as the utility and scalability levels they wish to achieve. Producers of products, services and applications should provide adequate information to controllers and processors regarding their use of pseudonymisation techniques and the security and data protection levels that these provide. Regulators (e.g. Data Protection Authorities and the European Data Protection Board) should provide practical guidance to data controllers and processors with regard to the assessment of the risk, while promoting best practices in the field of pseudonymisation. DEFINING THE STATE-OF-THE-ART In order to support a risk-based approach for pseudonymisation, the definition of the state-of-the- art in the field is essential. To this end, it is important to work towards specific use cases and examples, providing more details and possible options regarding technical implementation. The European Commission and the relevant EU institutions should support the definition and dissemination of the state-of-the-art in pseudonymisation, in co-operation with the research community and industry in the field. Regulators (e.g. Data Protection Authorities and the European Data Protection Board) should promote the publication of best practices in the field of pseudonymisation. ADVANCING THE STATE-OF-THE-ART While the focus of the report was on basic pseudonymisation techniques that are available today, the use of more advanced (and robust) techniques, such as those arising from the area of anonymisation, is very important for addressing the increasingly complex scenarios in practice. The research community should work on extending the current pseudonymisation techniques to more advanced solutions effectively addressing special challenges appearing in the big data era. The European Commission and the relevant EU institutions should support and disseminate these efforts. 6
Page 8
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 1. INTRODUCTION 1.1 BACKGROUND Pseudonymisation is a well-known de-identification process that has gained additional attention following the adoption of GDPR, where it is referenced as both a security and data protection by design mechanism. In addition, in the GDPR context, pseudonymisation can motivate the relaxation, to a certain degree, of data controllers’ legal obligations if properly applied. Given its growing importance for both data controllers and data subjects, ENISA published in 2018 [1] an overview of the notion and main techniques of pseudonymisation in correlation with its role under GDPR. In particular, starting from the definition of pseudonymisation (as well as its differences from other technologies, such as anonymisation and encryption), the report first discusses the core data protection benefits of pseudonymisation. Following this analysis, it then presents some techniques that may be utilised for pseudonymisation, such as hashing, hashing with key or salt, encryption, tokenization, as well as other relevant approaches. Last, certain applications of pseudonymisation are discussed, focusing especially on the area of mobile applications. Although the aforementioned ENISA’s work touches upon some of the key pseudonymisation issues, further research and analysis is necessary both to reinforce the concept of pseudonymisation as a security measure (art. 32 of GDPR) and to shape its role as a data protection by design instrument (art. 25 of GDPR). Indeed, as also recognised in the ENISA’s report, there is a particular need to promote pseudonymisation best practices and provide use case examples that could support the definition of the “state-of-the-art” in the field. Against this background, ENISA further elaborated under its 2019 work-programme on the practical application of data pseudonymisation3. 1.2 SCOPE AND OBJECTIVES The overall scope of this report is to provide guidance and best practices on the technical implementation of data pseudonymisation. More specifically, the objectives of the report are as follows: Discuss different pseudonymisation scenarios and relevant actors involved. Present possible pseudonymisation techniques in correlation with relevant adversarial and attack models. Analyse the application of pseudonymisation to specific types of identifiers, in particular IP addresses, email addresses and other types of structured data sets (use cases). Draw relevant conclusions and make recommendations for further work in the field. It should be noted that the selection of the uses cases was based on the fact that the specific types of identifiers (IP addresses, email addresses, identifiers in structured data sets) represent quite common cases in several real-life scenarios. At the same time, the selected use cases also reflect diverse requirements with regard to pseudonymisation, i.e. arising from the strict 3As ENISA is expected to provide guidance on aspects of network and information security policy in the EU, it is logical that addressing particular areas of interest, including in privacy and data protection, is a reasonable extension of its work and it meets stakeholders’ needs. Indeed, analysing the practical implementation of pseudonymisation is an important element towards security of personal data, as depicted under article 32 GDPR. 7
Page 9
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 format of IP addresses to the more flexible structure of email addresses and the unpredictable nature of larger datasets. The target audience of the report consists of data controllers, data processors and producers of products, services and applications, Data Protection Authorities (DPAs), as well as any other interested party in data pseudonymisation. The document assumes a basic level of understanding of personal data protection principles and the role/process of pseudonymisation. For an overview of data pseudonymisation under GDPR, please also refer to previous ENISA’s work in the field [1]. The discussion and examples presented in the report are only focused on technical solutions that could promote privacy and data protection; they should by no means be interpreted as a legal opinion on the relevant cases. 1.3 OUTLINE The outline of the report is as follows: Chapter 2 provides the terminology used in the remainder of the report with relevant explanatory remarks where needed. Chapter 3 refers to the most common pseudonymisation scenarios that can be expected in practice. Chapter 4 describes the possible adversarial and attack models with regard to pseudonymisation (and the previously described scenarios). Chapter 5 presents the main pseudonymisation techniques and policies that are available today. Chapters 6, 7 and 8 analyse the application of different pseudonymisation techniques to IP addresses, email addresses and more complex datasets (use cases). Chapter 8 summarises the previous discussions and provides the main conclusions and recommendations for all related stakeholders. This report is part of the work of ENISA in the area of privacy and data protection4, which focuses on analysing technical solutions for the implementation of GDPR, privacy by design and security of personal data processing. 4 https://www.enisa.europa.eu/topics/data-protection 8
Page 10
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 2. TERMINOLOGY This Chapter presents a number of terms that are used throughout the report and are essential to the understanding of the reader. Some of these terms are based on GDPR, whereas others refer to technical standards or are explicitly defined for the purpose of this report. In particular, the following terms are utilised: Personal data refers to any information relating to an identified or identifiable natural person (data subject); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person (GDPR, art. 4(1)). Data controller or controller is the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data (GDPR, art. 4(7)). Data processor or processor is the natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller (GDPR, art. 4(8)). Pseudonymisation is the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person (GDPR, art. 4(5))5. Anonymisation is a process by which personal data is irreversibly altered in such a way that a data subject can no longer be identified directly or indirectly, either by the data controller alone or in collaboration with any other party (ISO/TS 25237:2017)6. Identifier is a value that identifies an element within an identification scheme7. A unique identifier is associated to only one element. It is often assumed in this report that unique identifiers are used, which are associated to personal data. Pseudonym, also known as cryptonym or just nym, is a piece of information associated to an identifier of an individual or any other kind of personal data (e.g. location data). Pseudonyms may have different degrees of linkability (to the original identifiers)8. The degree of linkability of different pseudonym types is important to consider for evaluating the strength of pseudonyms but also for the design of pseudonymous systems where a certain degree of linkability may be desired (e.g. when analysing pseudonymous log files or for reputation systems)9. 5 See also relevant technical definitions of pseudonymisation in [1]. 6 See further analysis, including the difference between pseudonymisation and anonymisation in [1]. 7 The Article 29 Data Protection Working Party [31] refers to identifiers as pieces of information, holding a particularly privileged and close relationship with an individual, which allows for identification. The extent to which certain identifiers are sufficient to achieve identification is dependent on the context of the specific personal data processing. Hence, identifiers may be single pieces of information (e.g. name, email address, social security number, etc.) but also more complex data. 8 To this end, it could be stated that a pseudonym is a type of “disguise” of an individual’s identifier that, depending on the context, could make such individual more or less identifiable. 9 For a more detailed discussion on the degrees of linkability of pseudonyms, see in [4]. 9
Page 11
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 Pseudonymisation function, denoted 𝑃, is a function that substitutes an identifier 𝐼𝑑 by a pseudonym 𝑝𝑠𝑒𝑢𝑑𝑜. Pseudonymisation secret, denoted 𝑠 is an (optional) parameter of a pseudonymisation function 𝑃. The function 𝑃 cannot be evaluated/computed if 𝑠 is unknown. Recovery function, denoted 𝑅, is a function that substitutes a pseudonym 𝑝𝑠𝑒𝑢𝑑𝑜 by the identifier 𝐼𝑑 using the pseudonymisation secret 𝑠. It inverts the pseudonymisation function 𝑃. Pseudonymisation mapping table is a representation of the action of the pseudonymisation function. It associates each identifier to its corresponding pseudonym. Depending on the pseudonymisation function 𝑃, the pseudonymisation mapping table may be the pseudonymisation secret or part of it. Pseudonymisation entity is the entity responsible of processing identifiers into pseudonyms using the pseudonymisation function. It can be a data controller, a data processor (performing pseudonymisation on behalf of a controller), a trusted third party or a data subject, depending on the pseudonymisation scenario. It should be stressed that, following this definition, the role of the pseudonymisation entity is strictly relevant to the practical implementation of pseudonymisation under a specific scenario10. However, in the context of this report, the responsibility for the whole pseudonymisation process (and for the whole data processing operation in general) always rests with the controller. Identifier domain / pseudonym domain refer to the domains from which the identifier and the pseudonym are drawn. They can be different or the same domains. They can be finite or infinite domains. Adversary is an entity that tries to break pseudonymisation and link a pseudonym (or a pseudonymised dataset) back to the pseudonym holder(s). Re-identification attack is an attack to pseudonymisation performed by an adversary that aims to re-identify the holder of a pseudonym. 10 Note that under the definition of pseudonymisation in GDPR (article 4(5)), there is no reference as to who holds the additional information. 10
Page 12
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 3. PSEUDONYMISATION SCENARIOS As discussed in [1], pseudonymisation has an important role in GDPR as a security measure (art. 32 GDPR), as well as in the context of data protection by design (art. 25 GDPR). The most obvious benefit of pseudonymisation is to hide the identity of the data subjects from any third party (i.e. other than the pseudonymisation entity) in the context of a specific data processing operation. Still, pseudonymisation can go beyond hiding real identities into supporting the data protection goal of unlinkability [2], i.e. reducing the risk that privacy-relevant data can be linked across different data processing domains. Furthermore, pseudonymisation (being itself a data minimisation technique) can contribute towards the principle of data minimisation under GDPR, for example in cases where the controller does not need to have access to the real identities of data subjects but only to their pseudonyms. Last, another important benefit of pseudonymisation that should not be underestimated is that of data accuracy (for a more detailed analysis of the role of pseudonymisation, see in [1]). Taking the aforementioned benefits into consideration, this Chapter presents different pseudonymisation scenarios that can be found in practice, listing the various actors and the specific goals of pseudonymisation in each case. 3.1 SCENARIO 1: PSEUDONYMISATION FOR INTERNAL USE A common data pseudonymisation scenario is when data are collected directly from the data subjects and pseudonymised by the data controller, for subsequent internal processing. Figure 1: Pseudonymisation example Scenario 1 In Figure 1, the data controller (Alpha Corp.) has the role of the pseudonymisation entity, as it performs the selection and assignment of pseudonyms to identifiers. It must be pointed out that the data subjects do not necessarily know nor learn their particular pseudonym, as the pseudonymisation secret (e.g. the pseudonymisation mapping table in this example), is known only to Alpha Corp. The role of pseudonymisation in this case is to enhance the security of personal data 11
Page 13
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 either for internal use (e.g. sharing between different units of the controller)11 or in the case of a security incident. 3.2 SCENARIO 2: PROCESSOR INVOLVED IN PSEUDONYMISATION This scenario is a variation of scenario 1, where a data processor is also involved in the process by obtaining the identifiers from the data subjects (on behalf of the controller). However, the pseudonymisation is still performed by the controller. Figure 2: Pseudonymisation example Scenario 2 In Figure 2, a dedicated data processor (Beta Inc.) is given the task to collect the identifiers from the data subjects and forward this information to a subsequent data controller (Alpha Corp.), which finally performs the pseudonymisation. The controller is again the pseudonymisation entity. An example for such a scenario might be a cloud service provider that hosts data collection services on behalf of the data controller. Then, the controller still is in charge of applying data pseudonymisation prior to any subsequent processing. The goals for pseudonymisation are the same as in scenario 1 (but this time a processor is also involved in the process). 3.3 SCENARIO 3: SENDING PSEUDONYMISED DATA TO A PROCESSOR Contrary to the previous case, in this scenario the data controller again performs the pseudonymisation but this time the processor is not involved in the process but only receives the pseudonymised data from the controller. Figure 3 shows a data controller (Alpha Corp.) collecting data and performing the task of data pseudonymisation (in its role as pseudonymisation entity). The difference with previous scenarios is that now this data controller forwards the pseudonymised data to a subsequent data processor (Beta Inc.), e.g. for statistical analysis, or persistent data storage. In this scenario, the protection goal provided by data pseudonymisation can unfold: Beta Inc. does not learn the identifiers of the data subjects, thus is not directly able to re-identify the natural persons behind the data (assuming that no other attribute that could lead to re-identification is available to Beta Inc.). In this way, pseudonymisation protects the security of the data with regard to the processor. 11 See also recital (29) GDPR as to the notion of “general analysis” for internal use. 12
Page 14
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 Figure 3: Pseudonymisation example Scenario 3 A variation of this scenario could be the case where the pseudonymised data is not sent to a data processor but to another data controller (e.g. in the context of a legal obligation of the original controller or another legal basis). 3.4 SCENARIO 4: PROCESSOR AS PSEUDONYMISATION ENTITY Another possible scenario is the case where the task of pseudonymisation is assigned by the controller to a data processor (e.g. a cloud service provider that manages the pseudonymisation secret and/or arranges the relevant technical facilities). Figure 4: Pseudonymisation example Scenario 4 Figure 4 shows a case where the personal data are sent by the data subjects to a data processor (Beta Inc), which subsequently performs the pseudonymisation, thus acting as the pseudonymisation entity on behalf of the controller (Alpha Corp). The pseudonymised data is then forwarded to the data controller. In this particular scenario, only the pseudonymised data are stored on the controller’s side. In this way, security at controller’s level is enhanced through data de-identification (e.g. in case of data breach at controller’s side).Still, in all cases the 13
Page 15
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 controller is able to re-identify the data subjects through the data processor. Moreover, security at processor’s side becomes of great importance. A variation of this scenario could be a case where several different processors are involved in the pseudonymisation process as a sequence of pseudonymisation entities (chain of processors). 3.5 SCENARIO 5: THIRD PARTY AS PSEUDONYMISATION ENTITY In this scenario the pseudonymisation is performed by a third party (not a processor) who subsequently forwards the data to the controller. Contrary to the Scenario 4, the controller in this scenario does not have access to the data subjects’ identifiers (as the third party is not under the control of the data controller). Figure 5 shows a case where the personal data are sent to a third party (Gamma SE), which subsequently performs the pseudonymisation, thus acting as the pseudonymisation entity. The pseudonymised data is then forwarded to the data controller (Alpha Corp). In this scenario, the data controller cannot directly or indirectly link individual data records to data subjects itself. In this way, security and data protection at controller’s level are enhanced in accordance with the principle of data minimisation. Such scenario can be applicable in cases where the controller does not need to have access to the identities of the data subjects (but only to the pseudonyms). Figure 5: Pseudonymisation example Scenario 5 This scenario could be very relevant to cases of joint controllership, where one of the controllers is performing the pseudonymisation (acting as the trusted third party - TTP in figure 5), and the other one only receives the pseudonymised data for further processing. An interesting variation of this scenario (that would require further analysis) could be the case where the TTP is distributed over more than one entities, which can only jointly create and revert pseudonyms (or possibly based on a secret sharing scheme), so that one does not have to put trust only into a single entity. 3.6 SCENARIO 6: DATA SUBJECT AS PSEUDONYMISATION ENTITY This is a special case of pseudonymisation where the pseudonyms are created by the data subjects themselves as part of the overall pseudonymisation process. 14
Page 16
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 As can be seen in the example of Figure 6, every individual generates his/her pseudonym, then forwards their data with this pseudonym onwards12. Figure 6: Pseudonymisation example Scenario 6 An example of such type of data pseudonymisation systems would be the use of the public key of a key pair in blockchain systems (e.g. Bitcoin) to produce the pseudonym. The goal of pseudonymisation in such case is that the controller does not learn13 the identifiers of the data subjects and the data subjects can be in control of the pseudonymisation process; of course, the responsibility of the overall pseudonymisation scheme still rests with the data controller14. Again this is in line with the principle of data minimisation and can be applied in cases where the controller does not need to have access to the original identifiers (i.e. the pseudonyms are sufficient for the specific data processing operation). 12 Note that the pseudonym may be the same or differ across different services/applications (see Chapter 5). 13 In the sense that the controller does not acquire any pseudonymisation secret allowing for direct re-identification. 14 See also GDPR article 11 that might be relevant to this case. 15
Page 17
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 4. ADVERSARY MODEL As mentioned in Chapter 3, the primary goal of pseudonymisation is to limit the linkability between a pseudonymised dataset and the holders of the pseudonyms and to thereby protect the identity of the data subjects. This type of protection is typically intended to counter the efforts of an adversary to perform a re-identification attack. This Chapter considers the possible adversarial models and different types of re-identification attacks that are important to pseudonymisation. To this end, the notions of insider and external adversaries are addressed, while examining their possible roles under the pseudonymisation scenarios discussed earlier in the report. Understanding these topics is an essential element for further analysing the use of pseudonymisation techniques in the following Chapters. 4.1 INSIDER ADVERSARIES According to the common understanding of the term in IT security, an insider is an adversary with specific knowledge, capabilities, or permissions (with regard to the target of the adversary)15. In the context of pseudonymisation, this implies that the adversary is in a position to gain information about the pseudonymisation secret and/or other relevant significant information. For example, considering the scenarios in Chapter 3, an insider could be on the controller’s side (e.g. an employee working for the controller) under scenarios 1, 2, 3 and 4. It could also rest on the processor’s side (e.g. a malicious employee of a contractor) under scenarios 2 and 4. Last, in the case of scenario 5, the insider adversary could lie within the trusted third party (acting in this scenario as the pseudonymisation entity). By default third parties that might legitimately have access to the personal data (e.g. a supervisory or law enforcement authority) are not considered as adversaries16. 4.2 EXTERNAL ADVERSARIES In contrast to the insider adversary, an external adversary does not have direct access to the pseudonymisation secret or other relevant information. However, this type of adversary may have access to a pseudonymised dataset, and may also be able to perform the task of pseudonymisation to arbitrary input data values chosen by the adversary (e.g. by having access to a black box implementation of the pseudonymisation function, or by being able to force the pseudonymisation entity to pseudonymise arbitrary inputs). The goal of an external adversary is to increase his or her own information on the pseudonymised dataset, e.g. by learning the identity behind a given pseudonym (and acquiring further information on that identity from the additional data found in the dataset for the given pseudonym). Considering the scenarios of Chapter 3, by definition any actor who acts maliciously in all scenarios and is not part of the pseudonymisation entity or working on behalf of the pseudonymisation entity should be considered as an external adversary. A (malicious) data 15 According to the CERT Insider Threat Center at Carnegie Mellon University's Software Engineering Institute (SEI), an insider threat is being defined as the potential for an individual who has or had authorized access to an organisation's assets to use their access, either maliciously or unintentionally, to act in a way that could negatively affect the organisation, https://insights.sei.cmu.edu/insider-threat/2017/03/cert-definition-of-insider-threat---updated.html 16 It should be noted, however, that the legitimacy of such access could be challenged in cases where the data minimisation principle is not respected (e.g. a supervisory authority gaining access to the pseudonymisation secret rather than explicitly receiving only the personal data that it is entitled to receive). These scenarios would fall within the insider adversary model, as the third party has legitimately insider access, similarly to the pseudonymisation entity. 16
Page 18
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 controller could take the role of an external adversary under scenario 5 or 6. A (malicious) data processor could also take this role under scenario 3. 4.3 GOALS OF ATTACK ON PSEUDONYMISATION Depending on the context and the pseudonymisation method, the adversary can have different goals that he or she wants to achieve against pseudonymised data, i.e. retrieval of the pseudonymisation secret, complete re-identification, or discrimination. While most of the examples described in the next paragraphs focus on uncovering the “real” identity of the data subjects, it should be noted that a successful attack is not (only) a matter of reverse engineering, but more the capability of singling out a specific individual from a group (even if the “real” identity is not revealed). 4.3.1 Pseudonymisation secret In this case, the adversary focuses on discovering the pseudonymisation secret (i.e. when the pseudonymisation secret is used). This attack is the most severe one, as with the use of the pseudonymisation secret, the adversary is able to re-identify any pseudonym in the dataset (complete re-identification or discrimination), as well as to perform further pseudonymisation processes on the dataset. 4.3.2 Complete re-identification When the aim of the attack is complete re-identification, the adversary wishes to achieve the linking of one or more pseudonyms back to the identity of the pseudonym holders. This type of adversary has largely been discussed in the literature (see e.g. [3] [4] [5]). The most severe complete re-identification attack consists of the re-identification of all pseudonyms. The adversary can use two strategies to achieve this goal: recovering each identifier from the corresponding pseudonym independently; or recovering the pseudonymisation secret (see in 4.3.1). The least severe form of complete re-identification attacks involves an adversary who can only re-identify a subset of pseudonyms in the dataset. For example, consider a pseudonymised dataset of student grades of a university course. Each entry of the dataset contains a pseudonym corresponding to the identity of the student (name and surname) and a second pseudonym on the student's gender (e.g. by mapping male students to odd numbers and female students to even numbers). An adversary succeeds in a complete re-identification attack if he/she recovers the name, surname and gender of a student. 4.3.3 Discrimination The goal of the discrimination attack is to identify properties of a pseudonym holder (at least one). These properties may not directly lead to uncovering the identity of the pseudonym holder, but may suffice to discriminate him or her in some way. Considering the student grades example that was presented before, the dataset of student grades may contain two even numbers among many odd numbers as pseudonyms. Even numbers correspond to female students while odd numbers correspond to male students (this fact is known to the attacker). Both even numbers have scored 100% as result at the final exam. Further, let us assume that there are no other students that scored 100% in the pseudonymised dataset. If an adversary gains additional knowledge that a certain student scored 100% in this course, the attacker immediately learns that this student was female. Vice versa, if the adversary learns that a student of that course was female, the adversary immediately learns that this student had scored 100%. It is important to understand that the adversary does not learn the identity of a pseudonym holder here, but only learns some property (i.e. gender or grade value) of the holder. Given that several students share the same combination of property values, the adversary is not able to pinpoint the exact data record of a particular pseudonym holder. However, this extra information gained may already suffice for purposes of 17
Page 19
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 discrimination that the adversary intends to perform, or it may be utilised in a subsequent background knowledge attack to uncover the identity behind a pseudonym. 4.4 MAIN ATTACKING TECHNIQUES There are three main generic techniques to break a pseudonymisation function: brute force attacks (exhaustive search), dictionary search, and guesswork17. The effectiveness of these attacks depends on several parameters, including: The amount of pseudonym holder (data subject) information contained in the pseudonym. The background knowledge of the adversary. The size of the identifier domain. The size of the pseudonym domain. The choice and configuration of the pseudonymisation function utilised (this also includes the size of the pseudonymisation secret). These attacking techniques are briefly described next. 4.4.1 Brute force attack The practicality of this attack technique is conditioned on the adversary’s ability to compute the pseudonymisation function (i.e. there is no pseudonymisation secret) or his/her access to a “black box” implementation of the pseudonymisation function. Depending on the goal of the attack, extra conditions may apply. If the brute force attack is used to achieve complete re- identification (i.e. restoration of the original identity), the identifier domain must be finite and relatively small. For each pseudonym encountered by the adversary, he/she can attempt to recover the original identifier by applying the pseudonymisation function on each value of the identifier domain until he/she finds a match. Table 1: Pseudonymisation of month of birth Month of birth Pseudonym Month of birth Pseudonym Jan. 281 Jul. 299 Feb. 269 Aug. 285 Mar. 288 Sept. 296 Apr. 291 Oct. 294 May 295 Nov. 307 Jun 301 Dec. 268 Let us consider the pseudonymisation of a month of birth in a dataset. The size of the identifier domain is 12, thus an adversary can enumerate quickly all the possibilities. The pseudonyms associated to each month are computed in this case as the sum of the ASCII code of the first three letters of the month of birth (with the first being a capital one). Let us consider that an adversary has encountered the pseudonym 301. He or she can apply on each month of birth the pseudonymisation function until he/she finds the month which corresponds to the value 301. Table 1 shows the computations made by the adversary to re-identify pseudonym 301 resulting in the mapping table of the pseudonymisation function. 17 It should be noted that, as mentioned earlier in the document, other attributes (apart from the pseudonym and the pseudonymised data) may also be used to identify the individual. See also Chapter 8 for further discussion. 18
Page 20
PSEUDONYMISATION TECHNIQUES AND BEST PRACTICES NOVEMBER 2019 Obviously, the size of the identifiers domain is critical to successfully mount this attack. For small identifiers domains, like in the example presented above, a brute force attack is trivially feasible. If the identifiers-domain size is infinite, the brute force attack typically becomes infeasible. If the size of the identifiers domain is too large, complete re-identification is extremely difficult, leaving the adversaries with the potential of a discrimination attack. Indeed, in such case the adversary can consider a subdomain of the identifiers domain for which he or she can compute all the pseudonyms. Let us come back to the example of Table 1, while assuming that the domain is small. Let us assume that the adversary wants to discriminate people with a month of birth starting with the letter J from those starting with a different letter. This subdomain contains January, June and July. The adversary can mount an exhaustive search on this subdomain by computing the pseudonyms corresponding to January, June and July. If he or she finds a pseudonym different from 281, 301 and 299 then he or she knows that the month of birth is not starting with the letter J. In the case where a pseudonymisation secret is used, even a small identifier domain may not allow mounting such an attack (since the attacker is not able to compute the pseudonymisation function and provided that there is no access to a “black box” implementation of this function). In such a case, a brute force attack can be mounted over the entire space of pseudonymisation secrets – namely the attacker exhaustively checks all the possible secrets and, for each of them, he or she computes the recovery function. This attack will be successful if the attacker correctly guesses the pseudonymisation secret, regardless of the size of the identifier domain. Therefore, to thwart such an attack, the number of possible pseudonymisation secrets should be sufficiently large so as to render the attack practically impossible. 4.4.2 Dictionary search Dictionary search is an optimisation of brute force attack, which can save computation costs. The adversary has to deal with a large amount of pseudonyms to carry out complete re- identification or discrimination. Therefore, he or she precomputes a (huge) set of pseudonyms and saves the result in a dictionary. Each entry in the dictionary contains a pseudonym and the corresponding identifier or information. Each time the adversary needs to re-identify a pseudonym, he/she is going to search into the dictionary. This search has a pre-computation cost of an exhaustive search and stores the result in large memory. The re-identification of a pseudonym has only the cost of a lookup in the dictionary. The dictionary search is essentially the computation and storage of the mapping table. Time/memory trade-offs are even possible using Hellman tables [6] or rainbow tables [7] to further extend the range. However, there are specific variants of this attack that utilise additional knowledge on the way the pseudonymisation function works. Such attacks may even work for infinite input domains. 4.4.3 Guesswork This type of attack utilises some background knowledge (such as probability distribution or any other side information), which the adversary may have on some (or all) of the pseudonym holders, the pseudonymisation function, or the dataset. Implicitly, exhaustive search and dictionary search assume that all the identifiers have the same probability or frequency of occurrences. However, some identifiers may be more frequent than others. Exploiting the statistical characteristics of the identifiers is known as guesswork [8] [9] [10] and is widely applied in the password-cracking community. It is important to notice that guesswork can still be applied even when the identifiers domain is huge. The adversary does not necessarily need to have access to the pseudonymisation function (since discrimination is possible by simply performing a frequency analysis of the observed pseudonyms). Let us consider a case dealing with pseudonyms corresponding to ‘first names’. The domain of ‘first names’ is difficult to explore in its entirety. However, the adversary knows which ‘first 19
Affichage des 20 premières pages. Téléchargez le document pour le voir en entier.
Commentaires (0)
Aucun commentaire pour le moment. Soyez le premier !