Research

Detecting the source of an inconsistency

Auditors have no way of determining whether an inconsistency they detect was introduced by an outside attacker who compromised the key server, a system error, or a malicious employee. Currently, the only party that can be held accountable for an inconsistency is the identity provider. But identity providers don't want to lose the trust of their users because of a single malicious employee or because of an outside compromise. A high-assurance key server would minimize server bugs by using formal verification and secure hardware, but how can identity providers unambiguously prove that changes to the directory were made by a single malicious employee or caused by outside compromise?

Recovering from unintended inconsistencies

This problem is coupled with a CONIKS server's ability to detect the source of an inconsistency. Being able to prove the cause of an unintended inconsistency can help providers maintain their users' trust, but providers and users also need to return their system to a stable state after such an inconsistency has occurred.

Secure account recovery after key loss

Unlike passwords, which may be recovered when lost, there is no way to recover data encrypted for a lost key, which means a user would lose access to her account. A more user-friendly approach to account recovery, which is the current default in CONIKS, is to allow unauthorized key changes. However, this mechanism undermines users’ security since it doesn’t leave cryptographic evidence and other clients have no way of distinguishing account recovery from a compromised account. Therefore, it is crucial to develop a secure account recovery mechanism, in which it’s unambiguously clear who initiated the recovery. While key loss is also a problem in other applications such as Bitcoin wallets, we haven’t explored whether the solutions in those domains could apply to CONIKS.

Detecting false positives

False positives will cause a CONIKS client to issue warnings prompting the user about a possible attack. For example, the client will detect an unexpected key if the user adds a new device or re-installs the app to recover a lost account, as well as when the key server maliciously changes the user’s key without proper authorization. Similarly, a warning will be issued for inconsistent directory summaries, but these may stem from time synchronization problems between the server and the client, or from an attempt by a malicious key server to equivocate. It is crucial for the client to be able to distinguish between the innocuous causes for warnings and the attacks.

Effective user warnings

This problem is coupled with a CONIKS client's ability to detect false positives. Users are notorious for ignoring security warnings, so malicious CONIKS key servers may get away with attacks. Even if CONIKS clients have a mechanism for detecting false positives, how do we design a user interface that conveys clearly to users when it’s important for their security to take action on a warning?

Proactive attack prevention

By design, CONIKS detects attacks after-the-fact as inconsistencies are only detected once inconsistent signed tree roots have been published. While the detection guarantees are strong, they do leave an open window for attack, which depends on the frequency with which providers publish new STRs. Even though providers are required to publish temporary bindings whenever a client changes a key directory entry, these only serve as a non-repudiable promise by the provider to incorporate the changes in the following epoch. They don't prevent equivocation. Therefore, it is important to find a practical solution that is proactive and can mitigate the risks of key server compromise, instead of relying solely on a reactive system such as CONIKS.