Available witness OOBI list from KERIA to smoothen UX

[iFergal]

One of the user/UX challenges I see with wallets in particular is selection of witnesses and watchers. If every end user needs to know how to select witnesses then it will be a barrier to adoptability.

So I was considering the idea of KERIA announcing known witnesses it controls in its infrastructure and being able to update that list. Usage of non promiscuous witnesses for identifiers could be approved by the KERIA instance. This would lend itself to paid providers for KERIA with low user setup.

This does present some risks, particularly from a compromised KERIA updating the list of known witnesses. Maybe there are some mitigations here such as witnesses needing to sign this "updated list" etc, and having witnesses from other providers.

Curious to hear other people's thoughts.

[2byrds]

One of the user/UX challenges I see with wallets in particular is selection of witnesses and watchers. If every end user needs to know how to select witnesses then it will be a barrier to adoptability.

So I was considering the idea of KERIA announcing known witnesses it controls in its infrastructure and being able to update that list. Usage of non promiscuous witnesses for identifiers could be approved by the KERIA instance. This would lend itself to paid providers for KERIA with low user setup.

This does present some risks, particularly from a compromised KERIA updating the list of known witnesses. Maybe there are some mitigations here such as witnesses needing to sign this "updated list" etc, and having witnesses from other providers.

Curious to hear other people's thoughts.

I like the idea. When you say 'known witnesses it controls' do you simply mean that the company that hosts the KERIA service, also hosts the witness services?
I think it is good that you called out witnesses from other providers since it is generally important but especially worthwhile for greater security, even more so in this case

[iFergal]

Yeah, in the most basic case I meant that the company who hosts the KERIA also hosts the witnesses - this is probably not too different to what an enterprise experimenting with integrating KERI would do now in a pilot.

But yes, it would be a lot better to select witnesses from a mix of other providers to de-risk. Especially if witness rotation requires signatures from a threshold amount of prior witnesses.

Maybe this would be like a network of interconnected providers that use each other's witnesses (with some restrictions on load, or appropriate billing). Otherwise an end user would need to select a KERIA provider, and multiple witness providers (..and watchers) and become overwhelming to manage and just decide to revert to something less secure.

[SmithSamuelM]

In KERI Witness rotation is not constrained by prior witnesses. I.e only the controller signatures are needed to rotate witnesses not prior witness signatures. This enables a controller to recover from fully compromised witnesses.
The only requirement on a prior witness is that it publish the event that rotates it out. This provides a forwarding service to the new witness set. Obviously only an honest witness can be expected to satisfy this requirement. So if a witness set is fully compromised then it is up to the new witness set to publish to watchers and validators. One good reason to have sufficient witnesses in a pool is to ensure that the whole pool is not ever fully compromised, so that at least one honest witness remains from the old witness set as a known publisher to the new members of the witness pool.

This is a much less onerous condition than requiring that a majority of honest witnesses always be maintained which would be the case if prior witnesses were required to approve new witnesses.

[iFergal]

Thanks @SmithSamuelM - this was brought up quite some time ago in a dev call (in reference to "Joint Confirmed Witness Rotation" in the whitepaper) and I thought it was going to be enforced. I may have misunderstood and conflated it with forwarding. But great, that makes things easier!

What security advantage is there then with 2FA witnesses, if an attacker who compromised the pre rotated keys can change all the witnesses?

[SmithSamuelM]

Yes the "Joint Confirmed Witness Rotation" was a suggested optional feature. As the white paper indicates its comes with a significant drawback, as I meantioned above, of maintaining a majority of honest witnesses.

Given the added complexity and demands on controllers, it is not a required feature.

When adding a 2FA for a witness pool to publish a fully signed event, the controller is protected even in the event that the controller's prerotated key(s) are compromised but not a threshold number of 2FA factors for the witnesses because a witness won't witness the event unless it is both fully signed and satifies the 2FA with the controller..

So this is an simpler way to get a comparable level of security as joint witness confirmation. An attacker has to compromise both a threshold number of controller prerotated keys and a threshold number of witnesses (2FA) in order to publish a verifiable rotation event. And the 2FA can be updated differently than by publishing events, and can use more readily available mechanisms like an OTP or OTA.

[iFergal]

OK, thanks!

Regarding 2FA, perhaps I'm missing something. Without this feature, if all of the prerotated keys are compromised, can't the attacker just change the entire witness set to their own witnesses and publish this to watchers?

Or is this more related to it being more awkward for an attacker to spread the KELs to enough watchers? (if so would be interesting for watchers to be suspicious of complete swaps of witness sets and have a grace period for the controller to recover with the original witnesses)

[SmithSamuelM]

Witnesses provide high availability so the controller doesn't have to interact with each and every downstream validator. They also provide detectability against compromised signing keys.

To clarify, without 2FA, witnesses do not provide any meaningful security against compromised pre-rotated keys. But with 2FA then the attacker has to compromise both the pre-rotated keys and the 2FA of a threshold number of witnesses.

Cooperatively delegated AIDs also provide protection against the compromise of pre-rotated keys of the delegate. Since the rotation event won't validate unless the Delegator approves it.
So the attacker has to compromise the Delegator in addition to compromising the Delegate.

And even if the attacker compromises the Delegator the first time, The delegator and delegate can recover from a compromised rotation with a recovery rotation. This recovery of a rotation with another rotation is not possible with non-delegated AIDs.

So if both the delegate and delegator use 2FA with their witness sets, then an attacker has to compromise,

Delegate's prerotated keys
Delegate's witness 2FA threshold
Delegator's signing keys
Delegator's witness 2FA threshold
And do it twice in a row to make it unrecoverable.

[SmithSamuelM]

The main purposes of witnesses are

1. High availability of key state
2. Detectability of key state compromise

When witnesses are employed for non-delegated AIDs, any compromise of the signing keys of the controller MUST be published by the witnesses. This ensures the compromise is detectable, at the time of publication by the controller. Becasue no validator with accept an event that is not fully witnessed, the attacker can't exploit a compromise of the signing keys without being detected within the network latency of publication by the witnesses. No other security system, to my knowledge, has this assurance of near real time detectability.

The controller can then recover from the signing key compromise by issuing a recovery rotation that disputes the compromised signing keys and any events (ixn) that were so signed.

Compromise of pre-rotated keys does not have this protection. But pre-rotated keys are not needed to be exposed unless and until a rotation is required. This non-exposure means pre-rotated keys can be protected much better than signing keys. So the degree of difficulty of compromise of pre-rotated keys can be made arbitrarily high.

Therefore pre-rotated keys must be protected differently than signing keys. If pre-rotated keys are managed in such as way that they are just as easy to compromise as signing keys then this is an anti-pattern for using KERI.

Adding 2FA to the witnesses for all events provides an additional layer of security to both signing keys and pre-rotated keys. Or one could choose to only 2FA rotations and not 2FA interactions.

[iFergal]

To clarify, without 2FA, witnesses do not provide any meaningful security against compromised pre-rotated keys. But with 2FA then the attacker has to compromise both the pre-rotated keys and the 2FA of a threshold number of witnesses.

This makes sense to me if the witness set doesn't change.

If the attacker:

• compromises the pre-rotated keys of a non delegated identifier,
• creates a rotation event that removes all of the original witnesses and inserts all new witnesses from the attacker

Doesn't this effectively skip the need to compromise the 2FA, since those witnesses are removed?

[SmithSamuelM]

These are protections against live attack on the current key state. Witnesses also provide protection against dead attack on stale key state. Once a witness has witnessed an event it has first seen, it can't unsee it. It will never witness a duplicitous event. So an attacker has to compromise the witness to get it to "see" or witness an alternative event history. This provides a layer of protection against dead attacks without 2FA.

So to revise my list of witness properties

1. High availability of key state (dead and live)
2. Detectability of live signing key state compromise
3. Threshold protection against dead key state compromise (signing and pre-rotated)

If we add 2FA then we get additionally

4. Threshold protection against live signing key compromise and detectability of live pre-rotated key compromise (the later with caveats see below)

[SmithSamuelM]

Its easy to focus on live attacks and forget about dead attacks. This was the fatal flaw in did:TDW. They thought that all they had to care about were live attacks and "simplified" the method by dropping all the protections against dead attacks.

[SmithSamuelM]

if the attacker compromises the pre-rotated keys of a non delegated identifier,
creates a rotation event that removes all of the original witnesses and inserts all new witnesses from the attacker
Doesn't this effectively skip the need to compromise the 2FA, since those witnesses are removed?

Or is this more related to it being more awkward for an attacker to spread the KELs to enough watchers? (if so would be interesting for watchers to be suspicious of complete swaps of witness sets and have a grace period for the controller to recover with the original witnesses)

@iFergal Yes, you are correct. Sorry my answers were out of sync with these two questions and as a result, I need to caveat my list of protections to account for an attack that replaces all witnesses with fully compromised pre-rotated keys. I added a caveat in my list of protections above:

To clarify, as you point out, if the attacker compromises the pre-rotated keys and also rotates out all the witnesses and replaces them with witnesses of the attacker's choosing, then the attacker would have effectively bypassed the 2FA.

But this would be detectable by the controller unless the attacker also successfully eclipse attacks the watchers of the controller, and it should certainly be a cause for concern by any validator. This means validators may want to wait before accepting such a rotation.

All watchers may also have to re-oobi to the new witnesses, which in itself could be problematic.

These sorts of attacks are where the Judge role becomes useful. Because the Judge can evaluate or appraise such rotations as problematic and insert a time delay as you suggest, for example.

Given that the controller detects that the compromised rotation has occurred, the controller can issue an alternate rotation i.e. duplicitous rotation, thereby creating duplicity that a Judge would then use as evidence against accepting the suspicious rotation. The Judge could then OOB reconcile the duplicity with the controller. Of course, this is of no help for validators that are not using watcher pools with Jurors and Judges. So best to protect one's pre-rotated keys very well to prevent this sort of compromise.

In summary, the 2FA on witnesses does not provide full protection, as in prevention, from compromise of the live pre-rotated keys for non-delegated AIDs but does force the attacker to replace a threshold majority of the witnesses which by itself is a detectable event that can be used by validators to not trust the rotation and used by the controller to issue a competing duplicitous event thereby creating duplicity that requires a successful eclipse attack to overcome.

Notwithstanding the former, 2FA does prevent live attack on the signing keys, because signing keys can only be used to authenticate IXN events which do not change witnesses. Since signing key compromise is the most likely compromise, then 2FA with the witnesses requries compromising both the signing keys and the 2FA in order to even publish a compromised ixn event. The controller then does not have to deal with the complication of publishing a recovery rotation that disputes compromised events which prevents any forks in the KEL.

As I indicated above, using delegation does provide a prevention not merely a detection recovery protection for compromised pre-rotated keys. And the 2FA on the Delegator's witnesses then comes into play.

[SmithSamuelM]

Because KERI is about providing strong cryptographic protection, sometimes its easy to lose sight of the other considerations in an attack.

For example, replacing a full set of witnesses with witnesses controlled by the attacker in a single rotation, requires the attacker to stand up public infra-structure for those new witnesses. This comes at a cost. Because the witnesses have to be publically accessible by watchers, the attacker is traceable to that public infrastructure. This exposes the attacker to civil, criminal, etc liability and is in itself a disincentive to mount such an attack.

The vast majority of attacks take time for the attacker exploit, so they must remain undetected during this time, and un-traceable back to the attacker after detection.

But best to not have to depend on such protections. So as I indicated above, if one does not differentially protect ones pre-rotated keys, then that is an anti-pattern for using KERI.

[iFergal]

Thanks for the clarification @SmithSamuelM - makes complete sense!

In light of the original issue, I'd be interested to see if there would be a way to have a single 2FA with KERIA (if those particular witnesses have some trust in the KERIA instance), not sure. Not as secure as individually 2FA'ing with each witness but more adoptable from a UX perspective, which could be OK for less susceptible/critical identifiers.

Because the witnesses have to be publically accessible by watchers, the attacker is traceable to that public infrastructure. This exposes the attacker to civil, criminal, etc liability and is in itself a disincentive to mount such an attack.

Didn't think of this, very interesting!

[SmithSamuelM]

Because every action in KERI must be signed with non-repudiable digital signatures, every action, including those taken by attackers, becomes provably traceable to the signer. Thus, attackers can't attack anonymously in Keri. This is not true with conventional security systems that rely on repudiable shared secrets as authenticators like bearer tokens, passwords, shared encryption keys etc.

A single 2FA between a Keria instance and witnesses is a little more secure than no 2FA. I guess it depends on how one evaluates the cost/benefit tradeoff.

If it ends up being a shared secret then it probably would not deliver enough security and may give a false sense of more security than it actually does.

This is the bane of current security systems. They bolt on protection measures that are at best little more than security theater and at worst may induce users to engage in riskier behavior.

[iFergal]

Agreed, definitely want to avoid shared secrets.

I kind of meant more like a 2FA between just the controller and KERIA itself. And thereafter some signed propagation message from the KERIA agent containing the KEL (not a receipt) was received by witnesses in that infrastructure, they would receipt and publish.

So an attacker has to compromise (pre-rotated keys, KERIA) or (pre-rotated keys, 2FA) to keep the same witnesses. Not as good, but in some cases as you say could be OK given the cost/benefit analysis. Will think about it more though!

[iFergal]

Closing this for now as #318 suffices for me, for now.