Are PGP Key-servers Breaking the Law under the GDPR?

yakamo k
4 min readJul 6, 2018

--

I recently brought up this topic on a news site and got some very interesting points of view on the matter, this motivated me to explore the subject more.

I will make my point of view clear from the beginning i do believe that Key-Servers are breaking the law under GDPR specifically SKS Key-Servers(i do not have experience with others so i can not comment on them.).

Whats my goal with this article? It is to try and bring about change to the Key-Servers so they have a way for users to manage their data and to allow authority's and users to have illegal data removed.

First of all as stated by the maintainer of SKS Key-Servers, its “virtually impossible” to remove data from their servers.

I think this immortality of data on key-servers is a problem, if someone is unlucky enough to have their personal data dumped on to the Key-Servers without permission their is nothing they can do about it.

Example of what kind of data could be exposed

In this example i have exposed information of a person(fake person), as you can see this can be done by anyone, and there is no limit to the amount of information you can add to each key.

Under the GDPR this is a problem as it states in Article 25 Data protection by design and by default, Article 24(1) & 26, that Controllers(those running the key-servers in this case) need to have mechanisms in place that allow it to comply with the GDPR. For example, allow a user to withdraw consent to their data being used and then erased, this is stated in Article 17 (Right to erasure(‘right to be forgotten’)) & Article 7(3) (Conditions for consent).

The most important point here is in Article 17 1(d) where they state the right to erasure when the data has not been lawfully processed which would be the case for the above fake person i exposed, how ever once again there are no mechanisms in place to do this. In essence the Key-Servers would be breaking the law just by the fact they can not remove illegal or even copyrighted data. I am surprised this has not been an issue yet in an age where there is no shortage of malicious actors, maybe it is and no one has spotted it yet. I have looked through some dumped data from key servers and their is a lot of junk to sort through.

I wrote a simple PoC sofware that highlights how easy PGP Key-Servers can be abused.

Platforms like Facebook or Google are forced to obey the law and remove illegal content on a regular basis, and they have the mechanisms in place to do this weather it be a user reporting the illegal content or their AI finding it. They deal with it by closing the account and removing the content. I don’t see why Key-Servers should be any different or exempt from these legal issues.

If you run a service that stores the personal data of people and it is exposed to the public you have a responsibility for safely managing your systems in a responsible manner and keeping upto date with the law, in fact this is the whole point of the GDPR & the Data Protection Act.

keybase.io is an alternative to storing your PGP public key and even your PGP private key if your nutz. Keybase.io have ways for you to contact them easily and they can easily remove your account if you are found to be abusing it. Keybase.io also goes a lot further to verify your identity, unlike the out dated thinking of the current Key-Servers. This is not an advertisement for keybase.io it just seems to be the only alternative i know of, i have tried it and its not for me.

I would like to see someone use ActivityPub to create Key-Servers with accounts that are federated, this would allow users to manage their keys and provide a method for the removal of illegal content if it arises. This could also allow people to tie in their PGP key with other ActivityPub services for better security maybe.

Disclaimer i am not a lawyer! Seek Legal advice from a legitimate source if you need help on this matter.

If you have had issues with your data being dumped on key-servers without permission please leave it in the comments.

[Edit: corrected reference to section 59 to a clearer reference]

--

--