← Back to context

Comment by londons_explore

14 hours ago

I want whatsapp to decrypt the messages in a secure enclave and render the message content to the screen with a secure rendering pipeline, as is done with DRM'ed video.

Compromise of the client side application or OS shouldn't break the security model.

This should be possible with current API's, since each message could if needed simply be a single frame DRM'ed video if no better approach exists (or until a better approach is built).

Signal uses the DRM APIs to mitigate threats like Microsoft Recall, but it doesn't stop the app itself from reading its own data.

I don't really see how it's possible to mitigate client compromise. You can decrypt stuff on a secure enclave but at some point the client has to pull it out and render it.

  • > I don't really see how it's possible to mitigate client compromise

    Easy: pass laws requiring chat providers to implement interoperability standards so that users can bring their own trusted clients. You're still at risk if your recipient is using a compromised client, but that's a problem that you have the power to solve, and it's much easier to convince someone to switch a secure client if they don't have to worry about losing their contacts.

    • > Easy: pass laws requiring chat providers to implement interoperability standards so that users can bring their own trusted clients.

      In Europe that's called the Digital Markets Act.

      7 replies →

    • You seem to think the government wants your messages to be private and would "pass laws" to this effect.

      Methinks you put far too much faith in the government, at least from my understanding of the history of cybersecurity :)

  • >I don't really see how it's possible to mitigate client compromise.

    You could of course offload plaintext input and output along with cryptographic operations and key management to separate devices that interact with the networked device unidirectionally over hardware data diodes, that prevent malware from getting in or getting the keys out.

    Throw in some v3 Onion Services for p2p ciphertext routing, and decent ciphersuite and you've successfully made it to at least three watch lists just by reading this. Anyway, here's one I made earlier https://github.com/maqp/tfc

  • > don't really see how it's possible to mitigate client compromise.

    Think of the way DRM'ed video is played. If the media player application is compromised, the video data is still secure. Thats because the GPU does both the decryption and rendering, and will not let the application read it back.

    • That's not what signal's doing though. It's just asking the OS nicely to not capture screen contents. There are secure ways of doing media playback, but that's not what signal's using.

    • Video decryption+decoding is a well-defined enough problem that you can ship silicon that does it. You can't do the same thing for the UI of a social media app.

      You could put the entire app within TrustZone, but then you're not trusting the app vendor any less than you were before.

      3 replies →

  • By avoiding untrustworthy clients. All Windows devices should be considered compromised after last year.

  • This. The gap in E2E is the point at which I type in clear text and the point at which I read clear text. Those can be exploited.

“I want whatsapp to decrypt the messages in a secure enclave and render the message content to the screen with a secure rendering pipeline, as is done with DRM'ed video.“

If you are sophisticated enough to understand, and want, these things (and I believe that you are) …

… then why would you want to use WhatsApp in the first place?

  • Because my goal isn't to have my communication secure - but to have everyone's communication secure.

    And the network effect of whatsapp (3 billion users) seems currently the best route to that.

This is what a layman would assume happens from Meta’s WhatsApp advertising. They show the e2e process, and have the message entirely unreadable by anyone but the phone owner.