←back to thread

101 points eleye | 3 comments | | HN request time: 0s | source
Show context
JimDabell ◴[] No.45790549[source]
This is something I’ve been saying for a while[0,1]:

Services need the ability to obtain an identifier that:

- Belongs to exactly one real person.

- That a person cannot own more than one of.

- That is unique per-service.

- That cannot be tied to a real-world identity.

- That can be used by the person to optionally disclose attributes like whether they are an adult or not.

Services generally don’t care about knowing your exact identity but being able to ban a person and not have them simply register a new account, and being able to stop people from registering thousands of accounts would go a long way towards wiping out inauthentic and abusive behaviour.

[0] https://news.ycombinator.com/item?id=41709792

[1] https://news.ycombinator.com/item?id=44378709

The ability to “reset” your identity is the underlying hole that enables a vast amount of abuse. It’s possible to have persistent, pseudonymous access to the Internet without disclosing real-world identity. Being able to permanently ban abusers from a service would have a hugely positive effect on the Internet.

replies(6): >>45790613 #>>45790646 #>>45790899 #>>45791291 #>>45791379 #>>45791692 #
justsomehnguy ◴[] No.45790613[source]
> - Belongs to exactly one real person.

> - That a person cannot own more than one of.

These are mutually exclusive. Especially if you add 'cannot be tied to a real-world identity'.

replies(1): >>45790879 #
1. gruez ◴[] No.45790879[source]
The way that this is usually implemented is with some sort of HSM (eg. smart card, like on a e-id), that holds a private key that's shared with hundreds (or more) other HSMs. The HSM part ensures the key can't be copied out to forge infinite amounts of other identifies, and the shared private key ensures it's vaguely anonymous.
replies(1): >>45790937 #
2. eqvinox ◴[] No.45790937[source]
> - Belongs to exactly one real person.

I don't see how you can prevent multiple people sharing access to one HSM. Also, if the key is the same in hundreds of HSMs, this isn't fulfilled to begin with? Is this assuming the HSM holds multiple keys?

btw: "usually". Can you cite an implementation?

replies(1): >>45791794 #
3. gruez ◴[] No.45791794[source]
>btw: "usually". Can you cite an implementation?

u2f has it: https://security.stackexchange.com/questions/224692/how-does...

>I don't see how you can prevent multiple people sharing access to one HSM.

Obviously that's out of scope unless the HSM has a retina scanner or whatever, but even then there's nothing preventing someone from consensually using their cousin's government issued id (ie. HSM) to access a 18+ site.

> Also, if the key is the same in hundreds of HSMs, this isn't fulfilled to begin with? Is this assuming the HSM holds multiple keys?

The idea is that the HSM will sign arbitrary proofs to give to relying parties. The relying parties can validate the key used to sign the proof is valid through some sort of certificate chain that is ultimately rooted at some government CA. However because the key is shared among hundreds/thousands/tens of thousands of HSMs/ids, it's impossible to tie that to a specific person/id/HSM.

> Is this assuming the HSM holds multiple keys?

Yeah, you'd need a separate device-specific key to sign/generate an identifier that's unique per-service. To summarize:

each HSM contains two keys:

1. K1: device-specific key, specific to the given HSM

2. K2: shared across some large number of HSMs

both keys is resistant to be extracted from the HSM, and the HSM will only use them for signing

To authenticate to a website (relying party):

1. HSM generates id, using something like hmac(site domain name, K1)

2. HSM generate signing blob containing the above id, and whatever additional attributes the user wants to disclose (eg. their name or whether they're 18+) plus timestamp/anti-replay token (or similar), signs it with k2, and returns to the site. The HSM also returns a certificate certifying that K2 is issued by some national government.

The site can verify the response comes from a genuine HSM because the certificate chains to some national government's CA. The site can also be sure that users can't create multiple accounts, because each HSM will generate the same id given the same site. However two sites can't correlate identities because the id changes depending on the site, and the signing key/certificate is shared among a large number of users. Governments can still theoretically deanonymize users if they retain K1 and work with site operators.