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

so 12. 4. 2025 v 10:19 odesílatel Sean O'Brien <sean.obrien@yale.edu>
napsal:

> Hi Emelia,
>
> I don't think it's a four-alarm fire but it is an issue that has been on
> the backburner for far too long, especially with a few proposals from
> the community for years about how to approach the problem. I think there
> is currently a higher tolerance by end-users for taking the
> responsibility of key custody (mainly due to the spread of blockchain
> wallets) than there was years ago when AP was formalized.
>
> It's got to be taken seriously, and I think both Nostr and Bluesky will
> soon figure this out and draw a stark contrast to social communities
> based on AP in regard to encryption + privacy issues.
>

Hi Sean,

Thanks — agreed it’s not a four-alarm fire, but I do think it’s a core
architectural concern that’s been overlooked for too long.

Your identity model breakdown is helpful:

- Server owns identity — Facebook, ActivityPub

- Server owns identity with exit option — Bluesky, Mastodon?

- User owns identity — Matrix, Nostr

While each has trade-offs, storing private keys server-side creates a
serious risk — especially when personal data is involved. It allows
impersonation and removes meaningful boundaries between user and server.

We don’t need to pick one model as THE answer, but we should make the
security implications of each clear, and help those who want to adopt
stronger models.

It’s important that W3C RECs reflect how security evolves over time.

Best,
Melvin

>
> Cheers,
> Sean
>
> Sean O'Brien
> Research Fellow, Information Society Project (ISP) at Yale Law School
> Founder, Privacy Lab at Yale ISP https://privacylab.yale.edu
>
> On 4/12/25 04:06, emelia wrote:
> > Hi Melvin
> >
> > In no currently deployed major platform fpr the Fediverse is the Actor's
> keypair used for:
> > - End-to-End Encryption — "private mentions" in ActivityPub are NOT
> end-to-end encrypted
> > - The is no direct payments via ActivityPub, only via the ValueFlows FEP
> where payment happens in a side-channel (i.e., not dictated by the protocol)
> >
> > Yes, the current implementations may be storing the private keys in
> plaintext in the database (due to legacy reasons in the case of Mastodon),
> but even then with encryption it'd be a server managed encryption key,
> since the current architecture of S2S servers is that the server is the
> custodian of the private keys — not the end-user.
> >
> > That is to say: you'd need to completely change how you think about
> doing anything with the Actor's private keys to make it user-custodial,
> because the private key is used for signing outgoing requests that may
> happen in the background & it would necessarily make sense to send the
> users' active sessions a message going "hey, can you sign this HTTP request
> I need to make?" for HTTP Message Signatures.
> >
> > So yes, whilst we should be encrypting private keys in databases with a
> server-custodial key, that won't make the Actor's private key useful for
> payments or E2EE.
> >
> > That is to say, this isn't the four-alarm fire it may initially seem to
> be.
> >
> > – Emelia
> >
> >> On 12. Apr 2025, at 09:45, Melvin Carvalho <melvincarvalho@gmail.com>
> 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
>
>