• Dev

  • End-to-End Encryption GDPR Problems

  • [deleted]

  • Post #1
  • Edited

Mod Edit:
This discussion was originally part of https://discuss.flarum.org/d/23859-recruiting-testers-for-end-to-end-encrypted-private-messaging-extension/20

This opens up an awkward can of worms for GDPR in the sense that if you are requested by subpoena or similar court order to disclose information relating to any ongoing or incumbent case and it is encrypted, there will be issues arising from this in the sense that you are not able to provide the information requested.

Similarly, Nobody should expect any level of privacy on a system that is not owned by them, or the information is not stored on their device. All compliance departments in organisations will review all messages using keyword searches, and the inability to search an encrypted message is considered non-compliant by financial regulators. It is for this reason what when such financial institutions send an encrypted message, a non-encrypted copy is placed in the archive before submission to ensure it can be searched and presented as evidence in any court of law when requested.

As @Yalfoosh has already stated, true "private messaging" would indicate that nobody else - even in the case of a mod, can view the content of that message. In this case, it could only be classed as a DM (Direct Message). Encrypting the content is all well and good, but the ability to decrypt is paramount in certain legal situations. On the flip side, any conversation leaked via the DB will be encrypted if this ever took place (provided it's done at DB level and not on the fly in the browser of course).

My view is that we should stick with DM, and state in privacy policies that moderators both have access to, and reserve the right to view content and present in a court of law if requested.

Let's use the example of a terrorist cell or perhaps even a paedophile ring (extreme, but...) who decides to use your Private Messaging system for nefarious purposes, and you cannot see or moderate the content. It cannot be decrypted if you are using one-way encryption such as bCrypt, and therefore, you could not raise the alarm or alert local law enforcement or similar bodies should the need arise.

GDPR is one thing, but the local laws which fluctuate heavily dependant on jurisdiction is another. We could use @IanM "decontaminate" extension (which in itself would probably need refactoring) to eliminate PII automatically.

    Ralkage The thing is we already have Direct Messaging (Byobu) We do not have private messaging.

    [deleted] This opens up an awkward can of worms for GDPR in the sense that if you are requested by subpoena or similar court order to disclose information relating to any ongoing or incumbent case and it is encrypted, there will be issues arising from this in the sense that you are not able to provide the information requested.

    But GDPR requires you to implement end-to-end with a backdoor anyways, so that means that this issue, as well as others, don't actually exist, otherwise you're violating GDPR. Because it's likely that this extension's end-to-end would be self-hosted, the backdoor already exists in the form of you having the private keys (and not a third party). The question is only what kind of notification/logging would there be in the case of you decrypting stuff yourself. I'd be in favor of there being simple logging in case of a government intervention that requires confidentiality, with a mandatory user notification in case of a simple moderation intervention.

    That way you cannot actually personally abuse that you're someone with the access to the database without the user knowing (nor can any attacker), but you still allow pretty much everything direct messaging would allow.

          • [deleted]

          • Post #3

          Yalfoosh But GDPR requires you to implement end-to-end with a backdoor anyways, so that means that this issue, as well as others, don't actually exist, otherwise you're violating GDPR

          Not sure where you got this from, but that's completely untrue. One of the main benefits of encrypting information is to protect it in transit which is an industry standard and recommended as part of the GDPR. You'd be violating that same policy if you didn't encrypt the data or didn't take any basic steps to secure it. Similarly, GDPR does not require you to provide a back door for encryption.

              [deleted] Uhhh, yeah it does. Basically, if you keep data, and the consumer calls upon his right to access, you will have to be able to decrypt the data in order to give it to him. This indirectly means that you will have to have a backdoor.

              EDIT: To clarify, it's a combination of Article 12 and 15. 15 gives users the right to ask for their data. 12 forces you to provide that data, I cite:

              in a concise, transparent, intelligible and easily accessible form, using clear and plain language

              where encrypted data is obviously neither of those.

                  Yalfoosh @[deleted] specializes in GDPR and other privacy/security related topics. Reading through the GDPR myself (a none expert but fluentish) I see no provision or even round about way that the GDPR blocks end to end encryption. Further if GDPR does block end to end encryption then Facebook, Google, and many other companies are currently breaking GDPR as we speak.

                      tankerkiller125 It does not block it, it just says that you have to have a way around it. But maybe I'm mistaken, I'd be happy to hear the interpretation of Article 12 and 15 regarding end-to-end.

                          [deleted] But wait. In the case of this extension where it's possible that there won't be a third party who would host the keys, but you, you DO have access to the keys. I realize it's not really end-to-end encrypted since you could practically decrypt stuff yourself, but you'd have to decrypt stuff then upon request because you can, right?

                              • [deleted]

                              • Post #9

                              Yalfoosh this is also untrue. The point of this is encryption at rest and in transit. You are duly bound under GDPR regulation to protect both at rest and in transit data. You do not have to completely encrypt all data held about the user (but must be able to demonstrate applicable controls) and you must be able to present all of it in a subject access request if this is required. In most cases, what you would present as part of that would be plain text and not encrypted.

                              I think you've misunderstood the role of encryption when used alongside a regulatory control like GDPR.

                                [deleted] My thing though is that if the keys are generated on the client and stored by the client only and the provider has no way to read the messages how does that affect the GDRP data request process? My guess would be that the provider can just say that they can't access it?

                                    • [deleted]

                                    • Post #12

                                    tankerkiller125 that's correct. If they do not hold the keys to decrypt, then it's not possible. AWS for example of one such vendor who takes this approach. You lose the key, you lost access to your machines.

                                    Taking this route allows the host to exonerate themselves in the sense that they cannot be considered in scope when they possess no means of decrypting the content and can demonstrate that as part of their controls. This world also be covered by SOC 2

                                      Yalfoosh To clarify, it's a combination of Article 12 and 15. 15 gives users the right to ask for their data. 12 forces you to provide that data,

                                      With this kind of e2e isn't data then stored only at the client level and thus you as a forum owner are not the data processor of this PII and user data to begin with?

                                      PS. I have no idea whether data storage was previously discussed 🙈

                                          • [deleted]

                                          • Post #14

                                          luceos With this kind of e2e isn't data then stored only at the client level and thus you as a forum owner are not the data processor of this PII and user data to begin with?

                                          Yes. You can't be a custodian of data you do not control

                                            • [deleted]

                                            • Post #15
                                            • Edited

                                            Just to throw this in here, this is how political the GDPR can be as soon as you make personalised data from a home environment and then make it available to a wider audience via social media without consent

                                            BBC News - Grandmother ordered to delete Facebook photos under GDPR
                                            https://www.bbc.co.uk/news/technology-52758787

                                            Might help to chime in on some of the specifics of the encryption implementation.

                                            At the current state, admins will be completely unable to decrypt messages. The private keys for each user will be stored on the server but will be AES-256-GCM encrypted with the user's password ran through PBKDF2 with 12800 iterations to stretch it to 256 bits. The actual keys to decrypt messages are double ratchet keys, meaning they change after each use. If a hacker or admin managed to get ahold of one of these keys, they'd only be able to decrypt 1 message.

                                            Double ratchet creates a problem with reading old messages however. Once a message is read, it is simply encrypted with that same stretched password. If a user loses access to their password, he will lose access to previous messages as well.

                                            Any admin of Flarum or any other website could conceivably steal any of their user's passwords by using bad JS code. This could be mitigated in a few ways but makes the user experience significantly worse (having to export and manually keep track of keys).

                                            JS is at the moment is an inherently insecure programming language, I am taking as many steps as possible in the extension to prevent tampering by any party (including the admin) and I will make these steps clear in the final version. But once the code leaves my computer there isn't a lot I can do to JS to secure it from a bad admin.

                                              • [deleted]

                                              • Post #17
                                              • Edited

                                              Kyrne there's a couple of questions that arise from this methodology. JS isn't secure enough to guarantee maximum protection possible without the risk of tamper via inject and this creates an immediate security issue which on the face of it is likely insurmountable.

                                              If you consider how WordPress handles this from a plugin perspective, it is not encrypted. My question here would be why we need to encrypt messages in the first place in a forum. Based on the above, there should be an option to enable or disable depending on your preference. The messages are still private, but not encrypted and controlled by permissions instead.

                                                  [deleted] the JS code of the ext is verified using Subresource integrity which is a feature in JS. This means that as long as you are using https, the implementation is secure, no one but the site admin can tamper with the js code.

                                                  It's important to think about how apple could totally read your iMessages if they want, they just need to get your password which again is very possible.

                                                  The only way in the world to have 100% secure true end to end encryption is decentralized peer to peer messaging (the platform doesn't have control of the client). This is something no popular encrypted messaging service can provide

                                                      • [deleted]

                                                      • Post #19
                                                      • Edited

                                                      Kyrne that's correct of course in the sense of decentralised messaging, but what about the ability to disable or enable the encryption ? Requesting users to control their own keys is asking for it.

                                                          [deleted] The current system doesn't require users to manage their keys. My current plan is to release the ext as is, encryption required with little to no settings. After that, I will incrementally add features in order of popularity.