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

Hello all,

I would emphasise Emila's key point.

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

If the private keys in question were being used in "end to end encryption"
or financial transactions, then yes, this would be a big issue. But they're
not. They're essentially used to guard against spoofing. In that light, I'm
scratching my head a bit on concerns like this:

> It has limited my own ability to deploy social communities based upon
ActivityPub in an institutional or business context.

I'm probably missing something, but could you elaborate specifically on
why? What specifically about the current use of private keys in major
ActivityPub platforms causes concern in an institutional context? Could you
give an example?

This is not to say that the issue isn't relevant, rather that the enquiry
should be properly contextualised and focused, i.e. if ActivityPub
implementers want to support e2e encryption or financial transactions,
then, yes, better private key handling needs to happen. As far as I'm aware
major ActivityPub implementers don't currently support such things.
Probably the first question should be whether ActivityPub implementers
should support such things (via ActivityPub at least).

Cheers,

Angus

On Sat, Apr 12, 2025 at 10:18 AM Sean O'Brien <sean.obrien@yale.edu> wrote:

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