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

so 12. 4. 2025 v 22:09 odesílatel Evan Prodromou <evan@prodromou.name>
napsal:

> 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.
>

As AP is deployed, the publicKey links directly to the Actor (e.g.,
Mastodon spec) [1]. That suggests the key represents the user, not the
server — and cryptographically, the corresponding private key should remain
confidential to the user, if possible. Since it’s typically exposed to the
server (and anyone with access), I think the upcoming charter should
include something about a security review informed by 10 years of
implementation experience.

It reminds me a bit of the early web — for the first 10 years, HTTP was the
default, until deployment experience showed it wasn’t secure. Now HTTPS is
the norm. Similarly, over the past decade of the social web, the typical
pattern has involved leaking private keys to servers, allowing users to be
impersonated — but we’ve also learned that it’s possible, even practical,
for users to hold their own keys and identities, especially across the
wider fediverse.

[1] https://docs.joinmastodon.org/spec/activitypub/#publicKey

> 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
>
>