From 1ccd55b5f792773204060f6fc7b6d1898b5a50e2 Mon Sep 17 00:00:00 2001 From: Marcela M Date: Thu, 3 Nov 2016 19:57:57 -0400 Subject: [PATCH] [WIP] Preliminary registration protocol spec - Unrevised from https://github.com/coniks-sys/coniks-go/pull/86 --- protocol.txt | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 protocol.txt diff --git a/protocol.txt b/protocol.txt new file mode 100644 index 0000000..87e1d3d --- /dev/null +++ b/protocol.txt @@ -0,0 +1,139 @@ +Registration + +Prerequisites: This protocol requires that the client pin both the +server's public signing key for verifying signed tree roots (STRs) and +the server's initial private index verification key (i.e. the public +VRF key). We assume a separate PKI exists to manage the server's keys. + +Use of a CONIKS account verification bot is optional (see +https://godoc.org/github.com/coniks-sys/coniks-go/bots for details). +If the corresponding CONIKS key server requires that all registered names +be validated by a CONIKS registration bot, the client also pins the +registration bot that proxies all of its registration requests. +Additionally, as the network of CONIKS auditors is currently very small, +the client also maintains a list of pinned auditors. In a future release, +we plan to introduce an automatic update mechanism for the auditors list +while the development of a more scalable auditor discovery mechanism +is underway. + +Protocol: +- The user enters her username into the CONIKS client GUI prompt. + +- The client generates a new public-private key pair for this username, +and stores the keys in secure? local storage on the device. + +- The client sends a registration request + reg_req = (username, key) +to the server, or to the account validation bot, if used. See +https://godoc.org/github.com/coniks-sys/coniks-go/bots for the +CONIKS account validation protocol specification. + +- If the registration request is accepted*, the server returns a +registration proof. +More specifically, the server returns a proof of absence: + reg_pf = (auth_path, str) +If the server uses the temporary binding protocol extension, reg_pf will +also include a temporary binding (TB). See +https://godoc.org/github.com/coniks-sys/coniks-go/protocol/extensions/tb +for the temporary binding protocol extension specification. + +- The client audits the received STR including a hash chain check. +See https://godoc.org/github.com/coniks-sys/coniks-auditor for the +auditing protocol specification. *Note: Auditing is not implemented yet.* + +- Assuming the audit passes, the client proceeds to verify the TB, if +included: it verifies the server's signature on th TB and checks that +they public key in the TB matches the public key it sent to the proxy +in reg_req. + +- Next, the client verifies that auth_path is a proof of absence by +checking that its private index is invalid for the username, and its +commitment is invalid for the public key it registered in reg_req. +The client then recomputes the server's directory root using auth_path, +and verifies that str includes the recomputed root in its signature. + +- If the registration proof is invalid, the client notifies the user. The +Developing the reporting mechanism is planned for a future release. + +* The registration request may be denied for one of the following reasons: +(1) The client attempts to register a name that already exists in the +CONIKS key directory (ErrorNameExisted); the server returns a +privacy-preserving proof of inclusion in its response. (2) The server +encounters an internal error when attempting to register the name +(ErrorDirectory). + +Assumptions and Possible Attacks: The client accepts the STR in the +registration proof and assumes that the server has presented it with a +legitimate history with this initial STR (i.e. Tofu). +The main downside to the Tofu approach is that this does +allow a malicious server to place the client +on a forked branch of its history. However, by auditing the initial STR, +the client can detect this attack. Alternatively, the client could verify +the server's entire prior history to ensure that the server has not attempted +to equivocate about its initial STR. This approach would be more secure, +but has performance penalties. For now, we believe auditing will mitigate +this attack, but the need for a full prior history check upon registration +remains under discussion. + +As mentinoed above, for performance reasons, the client does not check +the server's prior hisotry upon registering a new name. This enables +a malicious server to remove a legitimate username from the directory +and allow another user to re-register the name as the registering +client would not discover the prior existence of the name. +The server is then able to deny service to the original user by allowing +another user to re-register the name and use the name. In the worst case, +the server is complicit in a malicious user's attempt to assume the +identity of the legitimate user. However, if the server has created a +fork in its history to equivocate and attempt to conceal this attack, +the client of the original owner of the stolen username will detect +this attack via auditing and monitoring, and the registering client +will detect this attack during the auditing step of the registration +protocol. + +Not checking the server's prior history during the registration protocol +also allows a malicious server to register a username, and remove +this name from the directory when a legitimate user registers the same +name to allow for the registration request to succeed. Assuming the server +has created a fork in its history at the point of the legitimate +registration, it can attempt to equivocate about the name. However, the +registering client can detect this +attack during the auditing step of the registration protocol. + +What these attacks have in common is that they take advantage +of the fact that the registration protocol does not require the client +to verify the server's prior history allowing an illegitimate +re-registration of a username. As a countermeasure, CONIKS does not +currently allow re-registration of retired usernames, +i.e. the user has deactivated and forfeit her account thereby making her +username available for use by another user. The design decision is +necessary since an attacker who is aware of the retired status of a victim's +username may re-register this user's name in order +to assume the victim's identity and impersonate her. Checking the server's +prior history is an insufficient countermeasure to this attack as +the intention of the new registrant cannot be verified by the client. + +Other attacks related to registration include name-squatting +(i.e. registering large numbers of usernames in order +to sell the usage rights to interested users for a fee) and social +engineering attacks in which an attacker registers a victim user's +username in another service in order to trick the contacts of the victim +user into thinking that they are communicating with the legitimate user +via a CONIKS-backed communication service. + +In general, the CONIKS +registration protocol cannot prevent an attacker +from registering a name before a legitimate user does, so there is a chance +that an attacker may be able to impersonate a legitimate user. This risk +is slightly mitigated by the fact that usernames in CONIKS diretories +are unique, so the legitimate user can simply register a different +username much like she would had aother legitimate user claimed her +preferred username first. While preventing name-squatting +and social engineering is beyond the scope of CONIKS, it may +be possible to reduce the avenues for a priori-registration by an +attacker in the case when the attacker is an identity provider who +manages its users keys in a third-party CONIKS server. We have not +developed a mechanism to prevent this scenario, but we suspect that +we may be able to leverage the intiial communication between +the identity provider and its CONIKS server during registration to +bind the identity provider to any registration originating from its +accounts.