Privacy in SURFconext using polymorphic pseudonyms

Structure of SURFconext

Institutions create a link to SURFconext. SURFconext is then linked to a variety of service providers. Users can log in via SURFconext to those services using an account from the users’ own institution.

When a user logs in, the institution sends attributes about this person to SURFconext, such as their name, email address, date of birth or gender. The attributes are then filtered by SURFconext, so that the service provider only receives those attributes it needs. For some attributes, this will depend on the contents, whereas others will be filtered according to type of attribute.

Privacy

The attributes that are sent contain users’ personal data. This means that privacy will play a role. In order to protect the users, we do not want service providers to acquire more information than they need. This goal will be achieved to a great extent by filtering attributes. However, an undesirable situation also arises if various services are able to link the user profiles they have access to. If several services each have a small amount of information on a user, and they can link this data together, collectively, they will have a great deal of information about that user.

The  metadata  obtained by using SURFconext is also privacy-sensitive. The services someone uses can already reveal a great deal of information about that person.

All this privacy-sensitive information is sent via SURFconext, making SURFconext one giant privacy hotspot.

Pseudonyms

We would like to limit the information shared with service providers, but at the same time, these services want to know if the same user comes back to use that service again. Pseudonyms are used for this purpose. A pseudonym may be viewed as a random, long series of characters. SURFconext keeps a table containing users’ pseudonyms. For every service, the user will be assigned a different pseudonym, so that services cannot link the profiles of one user together. An example of one of these tables:

The institution sends the user name to SURFconext. Instead of sending this directly to the service provider, the pseudonym will be looked up in the database, and this information will be sent instead.

Polymorphic pseudonyms

This system can be improved by using polymorphic pseudonyms. Since these are based on a cryptographic processing technique, a database is not necessary. There are also advantages when it comes to privacy. Polymorphic pseudonyms actually look different for SURFconext each time, as a result of which it is no longer possible to determine which user is using a certain service. The images below show a comparison between the current situation and the situation using polymorphic pseudonyms.

The institution generates a polymorphic pseudonym for the students and employees of that institution. If someone wants to log in, one of these polymorphic pseudonyms will be sent to SURFconext. Once there, the polymorphic pseudonym will be customised for a specific service. The result is an encrypted pseudonym that can only be used by that specific service provider. The service provider then ‘unpacks’ the encrypted pseudonym, enabling it to obtain the user’s final pseudonym. Although both polymorphic and encrypted pseudonyms look different each time on the outside, the final pseudonym for a user with a particular service is the same each time. This ensures that SURFconext cannot see who is logging in. Even if someone logs in somewhere again later, SURFconext cannot determine whether or not this is the same user.

Polymorphic attributes

The attributes that SURFconext receives from the institutions are still legible. Some of these attributes are at least as identifying as the user name that we had replaced with polymorphic pseudonyms. In other words, if we do not do anything about this, we haven’t really made any progress. This is however possible if you also make the attributes polymorphic. The institution sends a polymorphic attribute to SURFconext. SURFconext cannot read the content of this attribute, but can transform it into an encrypted attribute which can only be used by a specific service provider. The service provider can unpack the encrypted attribute and thus receive the correct value for the attribute. It is still possible to filter which attributes are sent to a service, but the contents of the attribute can no longer be used for this purpose.

In Control

Thanks to polymorphic pseudonyms, institutions can maintain control over the data that they have for their students and employees. The more locations at which this data is stored, the greater the likelihood that something will go wrong somewhere and the data will wind up in the wrong hands. In the current situation, a considerable degree of trust is placed in SURFconext. The confidence that SURFconext does not have malicious intentions of abusing data is not so strange, but people also assume that SURFconext will not be hacked, and that no mistakes are being made with users’ personal data. It is still important to believe that SURFconext does not have a need to abuse personal data, but that the use of polymorphic pseudonyms will reduce the other risks considerably.

Pilot

We are now examining the concrete ramifications of using polymorphic pseudonyms. For primary and secondary education, Kennisnet uses Entree Federatie, a system that is comparable with SURFconext. We are currently discussing the possibility of carrying out a pilot programme in this Entree Federatie system with Kennisnet. We would also like to conduct a pilot with SURFconext. However, we really need your assistance in this regard, in order to test the system with actual institutions and services. Are you interested in polymorphic pseudonyms? If so, we would love to hear from you! Please contact hans.harmannij@surfnet.nl for further information.