Opened 4 years ago

Closed 20 months ago

#17961 closed project (wontfix)

Evaluate CONIKS as an authenticator

Reported by: arlolra Owned by: huyvq
Priority: Medium Milestone:
Component: Archived/Tor Messenger Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


CONIKS is a practical key management system in which identity providers maintain directories of public keys on behalf of users of end-to-end secure communication systems. Our main motivation for designing CONIKS was to address the drawbacks of current trust establishment methods: (1) users either have to "manually" verify each other's keys, which has been shown to be cumbersome and error-prone for the vast majority of users, or (2) their secure messaging provider manages their keys on their behalf but these keys are not protected against tampering by a malicious provider, or compromise/coercion by malicious outsiders.

CONIKS makes it easier for users (both "default" users and stricter security-conscious users) to establish trust since they don't have to worry about or even see keys, but they also don't have to trust the identity provider to not insert spurious keys into its key directory because the key directories are maintained in tamper-evident and publicly auditable data structures (similar to a Certificate Transparency log). CONIKS includes automatic key verification, directory audit, and key change and revocation protocols which a CONIKS-enabled messaging client runs in the background, and which are efficient enough to be run on today's mobile devices. Information in the key directories is also stored in a privacy-preserving manner to prevent enumeration of users or keys during the directory audits.

Child Tickets

Change History (6)

comment:2 Changed 4 years ago by masomel

Here are the main design and deployment questions we've discussed about CONIKS so far:

Q: Can Tor Messenger become a CONIKS provider although we don’t hand out identities?

A: To use CONIKS as a key verification system, Tor Messenger does not need to hand out identities to its users in its own namespace. As long as each end user has *some* name (which could be their Twitter handle or the name they use for XMPP), a public key can be bound to this name, and it’s this name-to-key binding that CONIKS would verify. The CONIKS server can be agnostic to the original namespace of each of the names. This makes for a heterogenous naming scheme, but what’s important is that each name is unique in the Tor Messenger namespace.

Q: If Tor Messenger acts as the CONIKS provider for users using a wide variety of naming schemes, how can we ensure that the @alice registered with the CONIKS server corresponds to the @alice identity on Twitter?

A: We can ask for a proof of ownership of the name, e.g. by sending an email with a confirmation code, a Twitter dm or an XMPP offline message. This isn’t an ideal solution but it does raise the bar for an attack because it would require the attacker to gain access to the account receiving the confirmation code, which seems to be enough of a deterrent in most cases today.

Q: Is it reasonable to ask each communication service provider, especially in a federated system like XMPP, to act as a CONIKS provider?

A: Convincing a large portion of providers to act as CONIKS servers would be a pretty difficult task. One idea could be to have a single CONIKS server for Tor Messenger, but to convince other service providers to act only as CONIKS auditors, which ensure that the CONIKS server is behaving properly (i.e. not equivocating or otherwise tampering with its users’ keys). We think that because communication service providers already look for ways to protect their users’ security and privacy, this could serve as an incentive to run a CONIKS auditor. Plus, as we show in the paper, the burden to be a CONIKS auditor is significantly lower, so that might help in convincing these services as well. We also imagine that third parties like the EFF could run CONIKS auditors.

Last edited 4 years ago by arlolra (previous) (diff)

comment:3 Changed 4 years ago by arlolra

This is underway as part of GSoC. Most of the work so far is happening here

comment:4 Changed 4 years ago by arlolra

Owner: set to huyvq
Status: newassigned

comment:5 Changed 4 years ago by arlolra

Type: defectproject

comment:6 Changed 20 months ago by traumschule

Resolution: wontfix
Status: assignedclosed

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

Note: See TracTickets for help on using tickets.