[HN Gopher] Towards Federated Key Transparency
___________________________________________________________________
Towards Federated Key Transparency
Author : bo0tzz
Score : 38 points
Date : 2024-06-07 08:22 UTC (14 hours ago)
(HTM) web link (soatok.blog)
(TXT) w3m dump (soatok.blog)
| jauntywundrkind wrote:
| > _Truthfully, I had been hoping to piggyback off one of those
| upcoming projects (which is focused more on public key discovery
| for SAML- and OAuth-like protocols) to build the Federated PKI
| piece for E2EE for the Fediverse._
|
| What project/spec is this?
| some_furry wrote:
| It's not public yet. The person I was collaborating with has
| had a rough year (including some medical stuff) and can't give
| me an ETA on when they'll finish their part.
| Janymos wrote:
| RE: make it mandatory that each instance will map usernames to a
| random 256-bit integer, check out Verifiable Random Function:
| https://en.wikipedia.org/wiki/Verifiable_random_function
| edude03 wrote:
| I'm probably missing some context - I don't really grasp the
| problem being solved or why it's related to the fediverse. Would
| an accurate summary be "how to make activitypub based systems end
| to end encrypted (by default?)" or more along the lines of
| "verified" identity like keybase?
| ineptech wrote:
| This is a directory of public keys, which every secure
| messaging app including Keybase must also have, but federated
| rather than centralized. That's a necessity for e2ee and it's
| very cool to implement it as an append-only version of the pub-
| sub messaging the fediverse already has.
|
| It has nothing to do with the identity verification a la
| Keybase, unfortunately, as that would be a really good and
| useful feature for the fediverse, but I think it would be a lot
| harder to do.
| some_furry wrote:
| Nothing prevents other people from stapling identity
| verification on top of this.
| rakoo wrote:
| Sending an encrypted message to someone is a problem solved for
| decades: get their public key, encrypt your message, send it.
|
| The real problem with encrypted communications is: how do you
| properly distribute public keys, make sure they receive it,
| they receive the right one, etc ?
|
| - giving them by hand, directly or through web of trust,
| doesn't scale
|
| - trusting a server involves... trusting it, which you might
| not be able to do for many reasons
|
| - use the first one you receive from your recipient (TOFU)
| kinda works, but it's not really enough
|
| The beginning of a solution here is general transparency for
| everyone: everyone sends their public key to everyone, everyone
| records everything, and so if someone else changes my key
| without my consent I can tell everyone "SOMETHING IS WRONG,
| THIS IS NOT ME". For scalability, of course, keys aren't sent
| to everyone. The nice thing with this is that by design you
| don't need to trust anyone, you just have to watch everything
| by yourself.
|
| Keybase still needs to trust all third-party services, although
| it's assuming that each one isn't super reliable and the real
| trust comes from multiple independent third-parties. It's
| slightly in the middle, with the advantage of reusing existing
| stuff, but the inconvenient of making said existing stuff more
| important
|
| What's the relationship with the fediverse ? None, really; the
| concept is generic for any kind of communication, but
| ActivityPub is slowly becoming a protocol for generic
| communication anyway so might as well do it for AP.
| skybrian wrote:
| I don't think the "right to be forgotten" works with immutable
| logging? It seems like the workaround of mapping usernames to a
| random number and not including that mapping in the transparency
| log would break the security, because it allows usernames to be
| changed arbitrarily without logging it.
| some_furry wrote:
| Unfortunately, I don't get to decide whether or not to comply
| with GDPR.
| skybrian wrote:
| Maybe someone who knows the GDPR better could say whether
| there are exceptions for essential services. When looking up
| a public key by username, securing that mapping _by username_
| is clearly essential. Without it, you don't have a secure
| service.
|
| It would be like setting up certificate transparency without
| logging domain names - no point.
| some_furry wrote:
| If GDPR says "this is okay to store forever and never
| forget", that makes my life easier. However, I don't live
| in the EU and cannot afford the cost to consult lawyers on
| this matter.
| NotEvil wrote:
| Sorry, but which part of security. User can't pretend to be
| another registered user. They won't have the private keys.
|
| What am I missing.
| skybrian wrote:
| The idea is that you can send a message to a complete
| stranger. How do you know you didn't send it to the wrong
| stranger? Suppose the user doing the lookup (by username)
| gets the wrong public key and sends a message to the wrong
| person? That's a man-in-the-middle attack. Redirecting
| someone's messages to someone else is pretty bad.
|
| People mostly don't use real names on Mastodon, so
| essentially, you are your username. Impersonating a username
| is like impersonating a domain name for a website.
| some_furry wrote:
| > The idea is that you can send a message to a complete
| stranger. How do you know you didn't send it to the wrong
| stranger?
|
| Are you talking about the directory server _in isolation_
| or how it 's going to be integrated into the E2EE for the
| Fediverse proposal? It's not clear for your comment which
| use case you're imagining.
|
| The thing is: With the E2EE proposal, you don't just
| encrypt something to a complete stranger based on the
| Directory Server's contents. Instead:
|
| 1. You poke their instance for their user ID, and which
| directory servers they use.
|
| You can have further client-side checks, gossip protocols
| about username<->ID mapping, etc. to keep the instance
| honest about which ID maps to which user. I just don't want
| to deal with GDPR's "right to be forgotten" and usernames
| (which may be PII) at this layer.
|
| 2. You poke the directory server for the public keys, and
| proofs of inclusion in the SigSum ecosystem; including co-
| witness signatures.
|
| 3. Your software verifies these proofs, automatically,
| client-side. It refuses to move forward if anything is
| amiss.
|
| 4. Now that you have an Ed25519 (or post-quantum) signing
| key, you then query the instance for one of their
| SignedPreKey bundles.
|
| 5. You verify the signature on the SignedPreKey bundle,
| then use that to establish an untrusted comunciation with
| the user in question.
|
| After step 5, if you want to verify their identity,
| something like Signal's safety number for user trust can be
| implemented to allow out-of-band verification.
|
| It's important to take a step back and think about what the
| instance admins can and cannot do to mess with this
| process.
|
| Scenario A. A new user wants to enroll in E2EE messaging.
| The instance admin can pretend to be them and push an
| AddKey on behalf of the user, thereby locking them out of
| enrolling. Evidence of this becomes immutable and public,
| and the user can mitigate this by getting the hell off that
| instance.
|
| Scenario B. A malicious admin wants to snoop on the private
| messages of a user that has previously enrolled. The
| protocol forbids AddKey messages from being published by
| anyone but the user that possesses an incumbent signing
| key, which the instance admin does not have. They are
| thwarted by this policy.
|
| Scenario C. A malicious admin remaps the user's ID and
| enrolls a new AddKey, and selectively reveals one ID to
| some users and another to other users. This would be a
| challenge to pull off in a useful way, since the API to get
| a user's ID from the instance to lookup in the Directory
| server will not necessarily reveal who's asking for it.
|
| Third parties that publicly map User IDs and broadcast them
| on Fedi can mitigate this issue by alerting users to a
| difference. Although this would be annoying to integrate
| with a transparency log, having a watchdog service that
| your client software polls to ensure others see the same
| ID. Even as simple as automatically posting "user@instance
| is now at <random id here>" every time it changes would
| make this sort of misuse easily discoverable.
|
| This is out of the scope of the Directory Server design,
| but worth considering for the overall E2EE system. Since
| the blog post was focused on the Directory Server design, I
| didn't feel like speculating when I wrote it.
|
| Scenario D. A malicious admin remaps the user's ID and
| enrolls a new AddKey, but instead of selectively revealing
| one at a time, replaces them for all future DMs for
| everyone. Client software can easily detect this attack by
| noticing that the user's ID has changed, but the user
| didn't publish a MoveIdentity to their new ID.
|
| Scenario E. A user loses all of their secret keys and wants
| to start the enrollment over again. The user asks the admin
| to perform the exact same steps as a malicious admin from
| Scenario D, but for legitimately honest reasons (i.e. the
| AddKey for the new identity actually came from the user).
|
| Ultimately, distinguishing Scenario D and E is a social
| problem, not a technology problem. Detecting the behavior
| doesn't necessarily mean malice.
___________________________________________________________________
(page generated 2024-06-07 23:02 UTC)