Re: Major Security Issue with AP: Server-Stored Private Keys in ActivityPub

Hey, Melvin.

This is entirely in line with the security model of ActivityPub. 
Identities originate with the server; data is canonically stored on the 
server.

The keys you're discussing are well-described here:

https://swicg.github.io/activitypub-http-signature/

They are authentication for server-to-server communications, and are in 
no way client private keys. I'd compare very clearly the use of SSL 
between SMTP servers.

People who want a secure social networking environment should only use 
servers provided by entities that they trust. So, self-hosted, family 
servers, cooperative servers, employer or university servers, or 
software-as-a-service servers.

If you're interested on the work to bring end-to-end encryption (E2EE) 
to ActivityPub, I highly recommend the work going on in our E2EE task force:

https://github.com/swicg/activitypub-e2ee/

This work is bringing Message-Layer Security (MLS) as a layer on top of 
the ActivityPub network. As an analogy, it's similar to the use of PGP 
in SMTP email, on top of the server-to-server SSL relationship.

Evan

On 2025-04-12 3:44 a.m., Melvin Carvalho wrote:
>
> Hi All,
>
> There’s a major security issue in the way most ActivityPub 
> implementations work today: private keys are typically stored on the 
> server, often in plain text or with minimal protection.
>
> This means:
>
>  *
>
>     Server admins or attackers can fully impersonate any user.
>
>  *
>
>     There is no real cryptographic boundary between the user and their
>     instance.
>
>  *
>
>     *End-to-end encryption is fatally compromised* — servers can
>     decrypt or forge "private" messages.
>
>  *
>
>     *Any financial use of ActivityPub (tipping, payments, tokens) is
>     wide open to theft*, since servers hold the keys that authorize
>     transactions.
>
> When the original Working Group formed, we didn’t yet know how 
> implementations would evolve. But now that we do, we can’t keep saying 
> that insecure defaults are a feature, not a bug. This is a core flaw 
> that undermines the promise of secure federation.
>
> If a new Working Group is formed, security issues such as this* need 
> be acknowledged and addressed* — including exploring models where 
> users control their own keys, not the servers.
>
> Looking forward to hearing thoughts,
>
> Melvin
>