Real World Crypto 2021 - Session 13: AnonymityRWC2021 · Real World Crypto
FB use a lot of client-side telemetry from their apps. They want to log data without associating it to the user. This is private logging.
If it’s aggregate data, then there’s no need to identify users. But if it isn’t, there are problems; how can they trust the log data with no user ID? And are de-identified logs useful for debugging issues?
So, they built PrivateStats. This uses Verifiable Oblivious PRFs to add trust to de-identified logs. They can determine that a log is from a legitimate user without being able to identify the user. To do this they use blinding / unblinding.
The system can handle 200k credentials per second!
Challenges: rate-limiting their de-identified logging requests to prevent abuse that they can no longer attach to a user. They limit the number of logging tokens per user and rotate the underlying key to invalidate issued tokens.
Attribute-based public key system: derivation of a public-private key pair from an attribute, and a main pub/priv keypair. See their paper for AB-VOPRF
Decentralized Identity? Currently, how to open a financial account online:
- make selfie vid - have to be very careful what you show
- it’s cumbersome, and open to fraud
With DCI: user generates PK/SK pair, then go to a trusted authority (like DVLC), who act as an issuer. Issuer provides a digital identity doc (e.g. digital driving licence) bound to the user’s public key. User can then go to a third party (a bank) and can prove aspects of their identity (e.g. residence, age) by presenting the digital credential and use private key to prove legitimate ownership of the credential.
Goals of DCI: improve user experience & reduce fraud.
But users may go further: they want to manage their own data. Some users who are disenfranchised by the state can now obtain credentials so they can present ID.
There are problems swept under the rug though…. is DVLC able to or willing to issue digital credentials? Not worth investing in without practical uses for the digital creds. Bootstrapping problem!
Then there’s users: passwords are hard enough to keep secure for users. What about their private keys? Digital-savvy users can’t even keep tabs on their bitcoins.
Enter…. DECO. This is a three-party handshake to replace TLS' two-party one. Problem with TLS is that once handshakes are over the session key is symmetric, and that is of no use for proving something to a third-party that wasn’t involved in the handshake.
DECO works with TLS 1.2/1.3 requiring no server modification!!
When Signal first introduced groups, all users in group see each other and all messages sent to the group. Messages were sent 1:1 from sender to each group member.
How then to ensure group members all see a consistent, shared view of the group members?
- most msging systems store group membership in clear on a server; members have roles like admin, and those are stored in clear too,
- this is very risky if the server is stolen, abused, or subpoenaed, reveals a lot about the graph. Not acceptable to Signal.
Signal distributes membership lists to all the users and don’t hold on servers. This turned out to be painful, e.g. network issues end up with users having inconsistent views of the group memberships. Not as good as storing membership on server. They want server to be unable to read group member lists, and for it to be impossible forge new group members.
Signal introduced Private Group System - deployed in Q4'20 to address this.
- A new group’s creator generates a secret key to be used to encrypt group changes, this is a group key
- when new members are added they are sent the group key in encrypted message
- they prove their identity to the server using a ZK proof, which allows the svr to decide they can be given an encrypted group membership list
- still trusts server to enforce access control, but server can’t read member lists or forge new memberships
Signal Private Groups can use this to support features:
- group adminstrators
- add-self-to-group via URL
- group video calling.