Are user (actor) signing keys stored in cleartext on disk?

[Jaennaet]

Hey folks. I've just started poking around the codebase, and while looking at how the PDS does actor key management I ran into this:

atproto/packages/pds/src/actor-store/index.ts

Lines 57 to 61 in 13636ba

	async keypair(did: string): Promise<Keypair> {
	const { keyLocation } = await this.getLocation(did)
	const privKey = await fs.readFile(keyLocation)
	return crypto.Secp256k1Keypair.import(privKey)
	}

Which looks like private signing keys are just being read off the filesystem as-is. Am I missing something crucial here?

[DavidBuchanan314]

I believe you're correct, but bear in mind that the repo signing keys are replaceable (e.g. via did:plc rotation keys) if they're ever compromised (and there's talk of rotating them on a more regular basis). Kinda like how your TLS private keys usually just sit on disk accessible by your httpd.

[Jaennaet]

But the thing is that you can do a lot of damage with those keys before anybody actually notices they're gone and has a chance to rotate them – that's placing a lot of faith in the IDS setup of every PDS out there.

Plus if the server's been compromised I'm not sure if it's guaranteed the admin will be able to do that rotation.

I do get your comparison with TLS keys, but I'm not quite sure I agree. They can have passphrases (although that absolutely does have its problems) or stored in a HSM/KMS for one, and somebody yoinking even an unencrypted TLS privkey wouldn't be comparable to stealing a user's signing key. The PDS situation seems to be closer to storing user passwords without encryption, although not quite as bad since there is at least the possibility of rotation.

While this isn't an unmitigated disaster, it's not exactly great and has huge potential for turning into an unmitigated disaster. Hoping that some poor on-call ops person will be able to rotate all exfiltrated keys if they manage to detect the breach in time wouldn't be a security practice that exactly inspires confidence, and this is assuming there even is an on-call ops person or proper IDS setup – community PDSs are going to be pretty heterogenous when it comes to how they're operated.

[DavidBuchanan314]

If you store keys on a HSM accessible by the PDS, then a compromised PDS is almost as bad as a compromised key.

fwiw, I plan to implement a "client-signed commits" feature in millipds, where the PDS doesn't hold any key material whatsoever.

[Jaennaet]

Ideally clients should have (effective) custody of their own keys exactly like you're proposing and that really should be the ultimate aim.

But still, even though eg. a KMS, or an OSS system akin to Hashicorp's Vault, or even just encrypting the keys with a passphrase stashed in an env var (like the admin password) wouldn't be ideal, just about literally anything would be a step up from storing the plaintext signing keys of all users on disk and hoping they'll be rotated before too much damage is done if they leak, wouldn't you agree?

"Perfect is the enemy of good enough" – it'll be faster to plan and implement small incremental improvements than it will be to plan and implement an overhaul of key custody, and they aren't mutually exclusive.

[Jaennaet]

The way the current situation looks to me is that if there's a path traversal vulnerability in either the PDS or its dependencies, signing keys could be exfiltrated without anyone even noticing.

[bnewbold]

We definitely support there being a diversity of PDS implementations with more advanced security features!