Pseudonymization method and computer system for carrying out said method

Abstract

A pseudonymization method, the method including: a. receiving a data subject identifier from a first data controller (1), the first data controller having a first data controller identifier; b. calculating a pseudonym seed based on the data subject identifier using a cryptographic mixing function based on a pseudonym seed generation key (2); and calculating a global pseudonym as a first hash-based message authentication code on the pseudonym seed using a global pseudonym key (3).

Description

[Technical field]

[0001] The present invention relates to a pseudonymization method The present invention further relates to a computer system for carrying out said method. [Background technology]

[0002] According to the EU General Data Protection Regulation 2016 / 679 (colloquially known as the "GDPR"), "pseudonymization" means 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 organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person. A range of state-of-the-art pseudonymization techniques has already been described, for example, by the European Union Agency for Cybersecurity.

[0003] The described techniques mainly focus on the case where a single data controller wants to pseudonymize the personal data of its data subjects. Such techniques do not solve the problem of privacy-preserving pseudonymous data linkage, for example, when several data controllers want to share data about their mutual data subjects. Some of the described solutions only describe how to pseudonymize and transmit safety-critical records in a public network, for example, without the possibility of linking such data to further data controllers, while respecting the privacy of those data subjects.

[0004] In order to be able to perform data linkage across different sources, e.g. data controllers, pseudonyms associated with the same person by different data controllers need to match. However, this may seriously threaten the rights and freedoms of data subjects, in which case unique pseudonyms are associated with the same person. If a data breach is experienced by a single data controller, the data subjects involved may be re-identified in several further data sets presenting the same pseudonym.

[0005] Therefore, the pseudonyms should be calculated such that different data controllers use distinct pseudonyms for the same data subject. However, in this scenario, a third party is needed to calculate and distribute the pseudonyms to the data controllers. Such a third party could maintain the link between different pseudonyms referring to the same data subject and provide a personal data linkage service.

[0006] However, problems may arise if this third party is implemented as a central entity, in that such a third party (or an attacker controlling it) may be able to derive the identity of a data subject both from the data it receives as input for computing the pseudonym and from the graph linking different pseudonyms related to the same subject, and finally from the characteristics of the data controller requesting the pseudonym.

[0007] Solutions that adopt this approach therefore suffer from an increased risk of re-identification of data subjects. Summary of the Invention [Problem to be solved by the invention]

[0008] It is an object of the present invention to provide an improved pseudonymization method that allows different data controllers to use different local pseudonyms while reducing the risk of re-identification of data subjects, even when sharing data about them with each other. [Means for solving the problem]

[0009] This object is achieved according to the invention by the first independent claim, which shows the technical features of the first independent claim.

[0010] To this end, a pseudonymization method is provided, the method comprising: a. receiving a data subject identifier from a first data controller, the first data controller having a first data controller identifier; b. calculating a pseudonym seed based on the data subject identifier using a cryptographic blending function based on the pseudonym seed generation key; c. computing a global pseudonym as a first hash-based message authentication code on the pseudonym seed using the global pseudonym key; Includes.

[0011] In such a way, different data controllers can use different local pseudonyms, for example based on a global pseudonym, knowing that the computed global pseudonym remains the same for a single data subject identifier, in other words, different pseudonyms referring to a single data subject can still be linked to the global pseudonym, allowing for example the exchange of information if desired.

[0012] Furthermore, global pseudonyms can be calculated and / or recalculated as needed and therefore do not need to be kept in a central repository, which has been found to reduce the risk of re-identification of data subjects and in fact make the central repository more stale.

[0013] According to a preferred embodiment of the invention, the method comprises the steps of: d. calculating a local pseudonym key as a second hash-based message authentication code on the pseudonym seed combined with the first data controller identifier using the local pseudonym key generation key; e. computing a local pseudonym based on the global pseudonym using a cryptographic blending function based on the local pseudonym key; f. Providing a local pseudonym to the first data controller; It further includes:

[0014] Such a calculated local pseudonym can be used by different data controllers as a local pseudonym without the need to provide the complete data subject identifier to a central authority.

[0015] According to a preferred embodiment of the invention, steps b to f are performed by a second entity separate from the data controller. Such an arrangement allows to further reduce the risk of re-identification of the data subject, since the global pseudonym can now remain unknown to the first data controller. Furthermore, the data subject identifier of the data subject preferably remains unknown to the second entity. Thus, the second entity cannot enumerate the identities of all data subjects for which a pseudonym has been requested, either by the first data controller or by the further second data controller. Furthermore, the second entity cannot be sure whether a data subject has received a pseudonym or not. The second entity can further reduce the risk of re-identification of the data subject by keeping the global pseudonym key and the local pseudonym key generation key secret.

[0016] According to a preferred embodiment of the present invention, the pseudonym seed calculation is b1. Calculating an encrypted data subject identifier based on the data subject identifier using a cryptographic blending function based on a random key, preferably also a random one-time key; b2. calculating a pseudonym seed based on the encrypted data subject identifier using a cryptographic mixing function based on the pseudonym seed key, where the pseudonym seed key is calculated based on the pseudonym seed generation key as a cryptographic mixing function based on a random key, and the first and / or second hash-based message authentication code is calculated over the cryptographic mixing function of the encrypted data subject identifier based on the pseudonym seed key; Includes.

[0017] Preferably, the generation of the random key and the pseudonym seed key is performed by a third entity separate from the data controller, also referred to as the first entity, and the second entity. Such an arrangement allows to further reduce the risk of re-identification of the data subject, since the encrypted data subject identifier is now determined by a random key, preferably by the data controller itself. Furthermore, the use of a third entity ensures the use of a random key instead of using a self-determined, possibly less random key. The third entity further ensures the security of the method by keeping the pseudonym seed generation key secret. More preferably, step b1 is performed by the data controller and step b2 is performed by a second entity separate from the data controller. Such an arrangement prevents the second entity from deriving information about the data subject identifier, since it calculates the pseudonym seed from an identifier that is now encrypted and cannot be decrypted by this second entity.

[0018] According to a preferred embodiment of the present invention, the distinct keys, the global pseudonym, the local pseudonym and the data controller identifier are bit sequences of predetermined length and the cryptographic mixing function is an exclusive or function. It has been found that such bit sequences allow for relatively easy computation.

[0019] According to a preferred embodiment of the invention, the shared pseudonym between the first data controller and a distinct second data controller is computed as a third hash-based message authentication code over the global pseudonym combined with a cryptographic blending function of the first data controller identifier and the second data controller identifier with the shared pseudonym key. It has been found that such an arrangement allows the computation of different shared pseudonyms for different data subjects depending on the data controllers involved.

[0020] According to a preferred embodiment, the first data controller identifier and the second data controller identifier are encrypted to compute a third hash-based message authentication code.

[0021] For further security, the third hash-based message authentication code is computed by a fourth entity separate from the first data controller and the second and third entities, which further ensures the security of the method by keeping the shared pseudonym key secret.

[0022] More preferably, the encryption of the first data controller identifier and the second data controller identifier is performed by a fifth entity separate from the first data controller, the second entity, the third entity and the fourth entity.

[0023] According to a preferred embodiment of the present invention, communication of data between the respective entities is signed and encrypted using asymmetric cryptography. Such communication allows the different parties to be more certain of the identity of the sending party and to avoid undesirable parties reading or modifying the communication between the different entities, especially when the communication network between the different entities is public, such as a computer network, e.g., the Internet.

[0024] According to an embodiment of the present invention, the third hash-based message authentication code is calculated according to a policy defined by the first data controller, such policy enabling the first data controller to define rules for sharing data with other data controllers.

[0025] It should be noted that in general, different steps of different embodiments of the method according to the invention can be distributed and computed in parallel with respect to one another, e.g. offering the possibility of improving the scaling of the method when many such steps need to be executed, e.g. when there are large amounts of data subjects, data controllers, etc.

[0026] It is (another) object of the invention to provide a computer system for carrying out the method according to the invention.

[0027] This object is achieved according to the invention by a computer system according to the second independent claim.

[0028] Additionally, the computer system comprises at least one computer programmed to carry out the method according to the invention.

[0029] According to an embodiment of the invention, the separate entities include separate computers programmed to execute the methods respectively performed at the separate entities, the separate computers being interconnected by a computer network. [Brief description of the drawings]

[0030] The present invention is further explained by the following description and the accompanying drawings. [Figure 1] FIG. 1 is a schematic diagram of a preferred embodiment of the present invention. [Diagram 2] FIG. 1 is a schematic diagram of a preferred embodiment of the present invention. [Diagram 3] FIG. 1 is a schematic diagram of a preferred embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] Description of the Invention The present invention will be described with respect to particular embodiments and with reference to certain drawings but the invention is not limited thereto but only by the claims. The drawings described are only schematic and are non-limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn to scale for illustrative purposes. The dimensions and relative dimensions do not necessarily correspond to reductions to actual implementations of the invention.

[0032] Moreover, the terms first, second, third, etc. in the specification and claims are used to distinguish between similar elements and are not necessarily intended to describe a sequential or chronological order. These terms are interchangeable under appropriate circumstances, and embodiments of the invention may operate in sequences other than those described or illustrated herein.

[0033] Moreover, terms such as top, bottom, upper, lower, etc. in the specification and claims are used for descriptive purposes and not necessarily for describing relative positions. Terms so used are interchangeable under appropriate circumstances, and the embodiments of the invention described herein can operate in orientations other than those described or illustrated herein.

[0034] Moreover, various embodiments, while referred to as "preferred," should not be construed as limiting the scope of the invention, but as exemplary ways in which the invention may be practiced.

[0035] The present invention relates to a pseudonymization method for pseudonymization of a data subject. The data subject may be, for example, an identifiable object for which a property is desired that it cannot be directly or indirectly identified without the use of additional information, such as an object with an identification number, for example a machine, such as a vehicle. However, preferably, the data subject is a person, preferably a natural person. The data subject has data associated with it. The data according to the invention is preferably sensitive and affected by privacy regulations, such as, for example, the aforementioned GDPR regulation. Such data may be, for example, a name, an identification number, location data, online identifiers, factors specific to a physical, physiological, genetic, mental, economic, cultural or social identity, in particular data revealing racial or ethnic origin, political opinions, religious or ideological beliefs, trade union membership, genetic data, biometric data, data relating to health, or data relating to the sex life or sexual orientation of a natural person. In order to protect the privacy of the data subject, it is desirable to pseudonymize this data.

[0036] Data in the present invention is processed by a data controller, which determines the purpose and means of processing. For example, the data controller collects sensitive data from data subjects and digitally stores the data for later use, e.g., research. The data controller may be, for example, a school, e.g., a university, a research institute, e.g., a hospital, a healthcare provider, e.g., a doctor, or other organizations, e.g., insurance companies, government agencies, or even a combination of these categories.

[0037] In order for any such data controller to create a pseudonym for a data subject, the method according to the invention comprises, in a preferred first step, receiving a data subject identifier 1 from a first data controller.

[0038] A data subject identifier is a preferably unique identifier for a data subject. For example, the data subject identifier may be based on a collection, e.g. a concatenation, of identification data related to the data subject. For example, the data subject identifier may be based on a concatenation, preferably in a predefined order, of the data subject's name, e.g. the data subject's first name and / or surname, at least part of the date of birth, preferably the entire date of birth, place of birth, identifying details of the data subject's siblings, etc.

[0039] For example, in a specific example, the data subject identifier is based on a concatenation of the data subject's name and / or a date related to the data subject, such as for example the date of birth. Preferably, the information used for the data subject identifier is in a predefined format. According to a preferred embodiment, the data subject's first name, indicated as firstName, the data subject's surname, indicated as secondName, and the date of birth, indicated as dateOfBirth, in a predefined format, such as for example two digits for the day, followed by two digits for the month and four digits for the year, also known as "ddmmaaaa", although other formats are possible, such as for example "mmddaaaa" or "aaaammdd" or "aaaaddmm". This data subject identifier is for example called a personal identifier (PID). It can be symbolically represented as follows: PID=firstName||secondName||dateOfBirth, where "||" is used as a symbol for concatenation. Furthermore, the set of identification data is preferably hashed in a hashed data subject identifier HID. For example, the PID is hashed to a HID of a predefined bit length, for example 512 bits. Preferably, a key derivation function should be selected that is relatively slow and relatively difficult to compute, preferably a cryptographic hash function performed repeatedly in a loop. For example, a password-based key derivation function, for example PBKDF2(), is used for the PID and the salt value. For example, the salt value is a preferably cryptographic hash value of the PID, for example a secure hash algorithm, for example Secure Hash Algorithm 2, for example SHA512(PID). The PBKDF2() function uses for example SHA512 as a pseudo-random function and a number of iterations, numIterations, for example up to 4500. This can be shown for example as HID=PBKDF2(PID, SHA512(PID), numIterations, 512b). The use of the HID allows the identity of the data subject to be hidden during further steps of the method according to the invention.

[0040] As part of the method, a cryptographic mixing function may be used. For example, the cryptographic mixing function may be a Boolean exclusive-or function (denoted as XOR()). In such a function, two values ​​of the same bit length may be combined into a new value of the same bit length as the original values, with the calculated value being the exclusive-or of the two original values. Note that the XOR() function is commutative and associative. Furthermore, inherent to the XOR() function is that if C=XOR(A,B), then B=XOR(C,A) and A=XOR(B,C). The cryptographic mixing function may be used based on a generated, e.g. random, key, e.g. K. For example, K is a value of the same bit length as HID. In such an embodiment, the data subject identifier is then further encrypted, e.g. by computing the exclusive-or of HID with K, denoted as XOR(HID,K).

[0041] According to one embodiment of the present invention, in the next step, a pseudonym seed (PS) is calculated. The pseudonym seed is preferably a number equal to K PSG Based on a hashed data subject identifier HID using a cryptographic blending function based on a pseudonymous seed generation key called K. For example, the cryptographic blending function can be a Boolean exclusive-or function (denoted as XOR()), where K PSG is a value having the same bit length as the hashed data subject identifier, e.g., HID. In such an embodiment, the hashed data subject identifier is then, for example, XOR(HID,K PSG ) denoted as K PSG It is further encrypted by exclusive-oring the HID with

[0042] In the next step, K GP A global pseudonym (GP) is computed as a first hash-based message authentication code on the pseudonym seed PS with a global pseudonym key denoted as 3.

[0043] Preferably, the first hash-based message authentication code is, for example, K GPIt is computed using an HMAC() function on PS using GP as the key, e.g., a keyed cryptographic hash function, e.g., a SHA512 keyed cryptographic hash function. This can be done, for example, by GP ) or, for example, if you use SHA512, GP=HMAC(SHA512,PS,K GP )

[0044] According to a preferred embodiment, PS is preferably calculated by an entity separate from the first data controller, and K PSG is unknown to the first data controller. This entity is preferably called, for example, a pseudonym generation provider or PGP.

[0045] To further reduce the risk of re-identification of the data subject in the present invention, the pseudonym seed can be calculated in two steps, for example from the first data controller and PGP respectively.

[0046] In a first step, the hashed data subject identifier is multiplied by the first data controller using a generated, e.g. random, key, e.g. K ROT For example, the cryptographic mixing function can be a Boolean exclusive-or function (denoted as XOR()), and K ROT is a value having the same bit length as HID. In such an embodiment, the hashed data subject identifier is then, for example, XOR(HID,K ROT ) denoted as K ROT The resulting encrypted data subject identifier may be denoted, for example, as EID. ROT The value of can change, for example, several times, each time EID is calculated, and thus K ROT is a so-called one-time key. According to a preferred embodiment, K ROT is provided by an entity separate from the first data controller.

[0047] Preferably, the pseudonym seed generation key is held by an entity separate from the first data controller, and more preferably, if applicable, also by an entity separate from the pseudonym generation provider, e.g., referred to as a cryptographic key provider or EKP. The cryptographic key provider in such an embodiment preferably keeps the pseudonym seed generation key secret from the first data controller and further entities, e.g., PGP, if applicable. According to such an embodiment, the EKP is first generated by first generating a random one-time key K as described above. ROT to the first data controller, which proceeds with the calculation of the EID. PSG and K ROT Using a cryptographic mixing function based on PS For example, the cryptographic mixing function may be a Boolean exclusive-or function (denoted as XOR()). In such an embodiment, K PSG Then, K PS =XOR(K ROT ,K PSG ) denoted as K ROT With K PSG K as the exclusive OR of PS By calculating PS The XOR() function is commutative and associative, and the XOR() function, K PSG =XOR(K PS ,K ROT ) and K ROT =XOR(K PSG ,K PS ) according to such an embodiment. PS is not shared with the first data controller, but is shared with PGP.

[0048] In a second step, according to such an embodiment, the encrypted data subject identifier is then XOR(XOR(HID,K ROT ),K PS )=XOR(HID,XOR(K ROT ,KPS ))=XOR(HID,K PSG )=XOR(EID,K PS ) denoted as K PS In such an embodiment, PGP encrypts the EID with K ROT , and therefore cannot compute the HID from the EID received by the first data controller. PSG It does not recognize the PS and cannot calculate the HID.

[0049] Thus, in such an embodiment, a pseudonym seed PS is calculated based on the encrypted data subject identifier EID using a cryptographic mixing function based on the pseudonym seed key. The pseudonym seed key is then calculated based on the pseudonym seed generation key as a cryptographic mixing function based on a random key. Thus, a first hash-based message authentication code is calculated over the cryptographic mixing function of the encrypted data subject identifier based on the pseudonym seed key.

[0050] According to a preferred embodiment, the calculated GP can be stored in a GP database, for example called the GPD. Preferably, the GPD is separate from the first data controller, so that the GP is not known to the first data controller. This is especially desirable if the first data controller wants to share its data with further, for example second, data controllers.

[0051] To identify a data controller, such as the first data controller, the data controller also has an identifier called a data controller identifier CID. The first data controller in the present example is therefore called, for example, CID1, the second data controller is therefore called, for example, CID2, etc. The data controller identifier is a value, such as, for example, a random value, which preferably uniquely identifies the data controller when using the method. Preferably, the data controller identifier is a value of a predetermined bit length, such as, for example, a 255-bit value encoded in base 64 format.

[0052] According to a preferred embodiment of the method, d. calculating a local pseudonymous key as a second hash-based message authentication code on the pseudonymous seed combined with the first data controller identifier using the local pseudonymous key generation key; e. Step 5 of computing a local pseudonym based on the global pseudonym using a cryptographic blending function based on the local pseudonym key; f. Step 6 of providing a local pseudonym to the first data controller; The further steps of:

[0053] This preferred method is shown, for example, in FIG.

[0054] A local pseudonym key is, for example, K LP The local pseudonymous key generation key is called, for example, K LPKG The second hash-based message authentication code is called LPKG This is similarly computed using an HMAC() function on PS combined with CID1 using, for example, a keyed cryptographic hash function, e.g., a SHA512 keyed cryptographic hash function, using, for example, K LP =HM(PS||CID1,K LPKG ) or, for example, if you use SHA512, K LP =HMAC(SHA512,PS||CID1,KLPKG ), where again, the symbol "||" is used to denote concatenation. Note that the PS can be based on, for example, the HID or EID as explained above.

[0055] If the first data controller needs to periodically reset the generated local pseudonym, a new local pseudonym, for example for reasons of a local security breach or to further increase security, K LP is K LP =HMAC(SHA512,PS||CID1||epoch,K LPKG ), where epoch represents a counter, e.g. starting at 0 and incrementing each time such a new local pseudonym is needed. Such an epoch avoids, e.g., having to generate new keys and having to regenerate the GP, thus affecting other agents in the method, e.g. PGP and / or EKP.

[0056] The local pseudonym is, for example, called LP. For example, the cryptographic mixing function can be a Boolean exclusive-or function (denoted as XOR()). In such an embodiment, GP is then calculated as LP=XOR(GP,K LP ) denoted as K LP It is further encrypted as LP by computing the LP as the exclusive OR of GP with

[0057] It should be noted that preferably steps b, more preferably b2, and c and d and e and f, together with the computation of LP if applicable, are performed by PGP, which is a different entity from the first data controller. Furthermore, PGP may store its key, K if applicable, GP and K LPKG and / or the first data controller keeps the identity of the data subject secret, e.g. the identity of the data subject itself, the HID, the EID, etc. Furthermore, if an EKP is involved, the EKP may PSGIt is preferable to keep the identity of the data subject private. In this way, critical information remains separated and different entities cannot easily link the information if any one of them is compromised, thus reducing the risk of re-identification of the data subject.

[0058] If the first data controller wishes to make public on the LP, it can calculate a different additional value based on the LP, for example by choosing a random value that is kept secret for each LP, adding or subtracting a multiple of that value from the LP, and using the result for publicizing. To further increase security, for different publications, CID1 can use different multiples of the secret random value chosen for the LP.

[0059] FIG. 2 shows a schematic diagram of the data flow between these different preferred entities.

[0060] When a first data controller wants to share data with another data controller, it can upload the GP to the GPD. This can be done by PGP or the first data controller. When the first data controller is responsible for uploading the GP to the GPD, the GP is preferably encrypted by PGP for the GPD, so that the first data controller is prevented from knowing the GP.

[0061] When the preferably encrypted GP is uploaded to the GPD, it can contain a sharing policy for sharing the data subject's data with other data controllers. In this way, the GPD collects GPs of different data subjects with different sharing policies of different data controllers.

[0062] If two data controllers, referred to by the data controller identifiers CID1 and CID2 as mentioned above, want to share data on a data subject, preferably 12A shared pseudonym, denoted by K, is calculated 7. Preferably, the shared pseudonym is calculated by the GPD, since the GPD preferably possesses different sharing policies with the GPs of the different data subjects involved. Preferably, the sharing policies are also kept secret by the GPD, in particular for the different data controllers. The shared pseudonym is preferably calculated by the GPD, in this case K SP The third hash-based message authentication code is calculated as a third hash-based message authentication code over the global pseudonym GP combined with a cryptographic blending function of the first data controller identifier CID1 and the second data controller identifier CID2 with a shared pseudonym key called K. SP The HMAC() function on the GP combined with a cryptographic blending function of the first data controller identifier CID1 and the second data controller identifier CID2 using the key, e.g. a keyed cryptographic hash function, e.g. a SHA512 keyed cryptographic hash function. This can be done, for example, using the SP 12 =HMAC(GP||XOR(CID1,CID2),K SP ) or, for example, if you use SHA512, SP 12 =HMAC(SHA512,GP||XOR(CID1,CID2),K SP ) where again, the symbol "||" is used to indicate concatenation.

[0063] Different SP 12 Upon receiving the request, CID1 sends the SP 12 By using this, you can initiate data sharing with CID2 on a pseudonymous data subject.

[0064] Since the GPD possesses different computed GPs connected to different data controller identifiers and their respective shared policies, the GPD can connect GPs to different data controllers and derive from its knowledge privacy-sensitive knowledge about the specific GP for which the data subject sought treatment, for example at a medical facility. Therefore, to further enhance security and / or reduce the risk of re-identification of the data subject of the method, a further step can be provided between the data controller and the GPD, where the respective CID values ​​are encrypted. More preferably, this encryption is performed by yet another entity, a fifth entity called pseudonym lookup provider or PLP.

[0065] This preferred embodiment is shown, for example, in FIG.

[0066] According to such an embodiment, the first data controller CID1 can request from the GPD, via the PLP, if applicable, a list of further data controllers in which the data subject of CID1 is also registered, possibly together with the corresponding applicable sharing pseudonyms used between the first data controller and each of the other data controllers, according to the applicable sharing policy, if applicable. Based on the obtained sharing pseudonym, the first data controller can then proceed to share information with the other data controllers according to the applicable sharing policy. However, if the two data controllers have already shared data directly with one of the data controllers based on the data subject's local pseudonym, they can continue to share data according to the defined sharing policy.

[0067] In a further embodiment, a third party, a data controller, for example a research institute, can receive data on data subjects from different data controllers, for example further first and second data controllers. To share data with a third party, the two data controllers publish their respective LPs, for example as described above. However, based only on the LPs of the two data controllers, the third party cannot derive from the different LPs, whether they relate to the same data subject or not. Thus, the data controller cannot link data between the two data subjects, for example, to better study the data of the data subjects shared between the two data controllers. To enable linking between different LPs from different data controllers, when sharing their LPs with a third party, the data controller can also share, preferably in encrypted form, the global pseudonym of the LP, received for example at the time of the creation of the LP. Thus, if a third party wants to link LPs from different data controllers, the third party can provide the GPs from the respective data controllers to the GPD, preferably encrypted for the GPD, but via the PLP if applicable. The GPD can then calculate the shared pseudonym of the global pseudonyms of the two data controllers according to the defined sharing policy, if applicable, as described above. For that purpose, the sharing policy may contain a specific sharing policy for this case of linking different LPs. If there is a shared pseudonym that matches a global pseudonym, this means that the two corresponding local pseudonyms actually refer to the same data subject and, if applicable, the sharing policy allows the data to be shared. This information can therefore be shared with third parties, allowing them to link the appropriate LPs. For example, via the PLP, if applicable, the GPD can share with third parties a mapping indicating which global pseudonyms, preferably encrypted global pseudonyms, are linked without the need to reveal further identifying data about the global pseudonyms, for example by sharing a shared pseudonym of the submitted global pseudonym, preferably encrypted global pseudonym.A third party in such a situation may, for example, set up an identifier, called a mesh identifier, to link together all local pseudonyms that in fact refer to the same data subject with the same shared pseudonym.

[0068] Preferably, the different entities CID, PGP, EKP, PLP, and GPD are separate and distinct entities from one another, and each keeps each other's keys secret from the other. Preferably, communication of data between the respective entities is signed and encrypted using asymmetric cryptography, especially when the communication is over a public network, such as an intranet or the Internet.

[0069] Although aspects of the present disclosure have been described with reference to specific embodiments, it will be readily understood that these aspects may be embodied in other forms.

Claims

1. 1. A method of pseudonymization, said method comprising: a. receiving a data subject identifier from a first data controller, the first data controller having a first data controller identifier; b. calculating a pseudonym seed based on said data subject identifier using a cryptographic blending function based on a pseudonym seed generation key (2); c. Computing a global pseudonym as a first hash-based message authentication code on the pseudonym seed using a global pseudonym key (3); Pseudonymization methods, including:

2. The method comprises: d. Computing a local pseudonym key as a second hash-based message authentication code on the pseudonym seed combined with the first data controller identifier using a local pseudonym key generation key (4); e. Computing a local pseudonym based on the global pseudonym using a cryptographic mixing function based on the local pseudonym key (5); f. providing said local pseudonym to said first data controller (6); The pseudonymization method of claim 1 further comprising:

3. 3. The pseudonymization method of claim 2, wherein the pseudonym seed is calculated based on an encrypted data subject identifier using the cryptographic mixing function based on a pseudonym seed key, the pseudonym seed key is calculated based on the pseudonym seed generation key as a cryptographic mixing function based on a random key, the encrypted data subject identifier is calculated based on the data subject identifier using the cryptographic mixing function based on the random key, and the first hash-based message authentication code is calculated over the cryptographic mixing function of the encrypted data subject identifier based on the pseudonym seed key using the global pseudonym key.

4. 4. The pseudonymization method of claim 3, wherein the second hash-based message authentication code is calculated over the cryptographic mixing function of the encrypted data subject identifier based on the pseudonym seed key combined with the first data controller identifier using the local pseudonym key generation key.

5. 4. The pseudonymization method of claim 3, wherein steps bf are performed by a second entity separate from the data controller.

6. The pseudonymization method of claim 5 , wherein the random key and the pseudonym seed key are generated by a third entity separate from the first entity and the second entity.

7. 4. The pseudonymization method of claim 3, wherein the different keys, the global pseudonym, the local pseudonym, and the data controller identifier are bit sequences of predetermined lengths, and the cryptographic mixing function is an exclusive-or (XOR) function.

8. 7. The pseudonymization method of claim 6, wherein a shared pseudonym between the first data controller and a distinct second data controller is computed as a third hash-based message authentication code of the global pseudonym combined with the cryptographic blending function of the first data controller identifier and the second data controller identifier with a shared pseudonym key.

9. 9. The pseudonymization method of claim 8, wherein the first data controller identifier and the second data controller identifier are encrypted to calculate the third hash-based message authentication code.

10. 10. The pseudonymization method of claim 9, wherein the third hash-based message authentication code is computed by a fourth entity separate from the first data controller, the second entity, and the third entity.

11. 11. The pseudonymization method of claim 10, wherein the encryption of the first data controller identifier and the second data controller identifier is performed by a fifth entity separate from the first data controller, second entity, third entity, and fourth entity.

12. 12. The pseudonymization method of claim 11, wherein communication of data between respective entities is signed and encrypted using asymmetric cryptography.

13. The pseudonymization method of claim 8 , wherein the third hash-based message authentication code is calculated according to a policy defined by the first data controller.

14. A computer system comprising at least one computer programmed to perform the pseudonymization method described in any one of claims 1 to 13.

15. 15. The computer system of claim 14, wherein the separate entities comprise separate computers programmed to perform the computations of the pseudonymization method each executed at the separate entities, the separate computers being interconnected by a computer network.

Images