2K/ Security Considerations of KERI. Why and how KERI provides secure portability

== Security Considerations of KERI. Why & How KERI Provides Secure Portability
==

Tuesday 2K

Convener: Sam Smith

Notes-taker(s): infominer

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

https://identity.foundation/keri/docs/Q-and-A-Security.html#part-two-security

Q: What are the security risks of KERI with regard to the identity protocol?

Harm that can be done to the a controller: Unavailability, loss of control authority, externally forced duplicity

Harm that can be done to a validator: Inadvertent acceptance of verifiable - but forged or duplicitous events

Breaking the promise of global consistency by a controller is a provable liability. However, global consistency may only matter after members of that community need to interact, not before.

(SamMSmith)

Q: How secure is the KERI infrastructure?

KERI changes the discussion about security. From a discussion about the security of infrastructure to a discussion about the security of your key management infrastructure. Most people when they think security, the think “oh, blockchain!”: permissioned or permissionless, how hard is it to get 51% attack, etc.None of that matters for KERI. KERI is all about “are your private keys private?!” And if yes, that drastically slims down the security discussion to brute force attacks to public keys. And because the next public keys are in fact protected by a hash, you have to brute force the hash algorithm, that is post-quantum secure. So that is a very high level of infrastructural security.

So private key management and protection is the root of your security in KERI.

Q: Can I rotate keys with Tangem in KERI?

Suppose I’d trust a Tangem card for generating public private key pairs at will and the NFC communication allowing to interact with a wallet app.

One of the main concerns is that there is a theoretical link (a binding) between the cards and a user, via the card-ID (CID). However the CID is used only for checking the authenticity and integrity of the chip itself. Tangem publishes and anchors a list of CIDs with corresponding public addresses in a public blockchain. When checking authenticity, the verifier looks up the pub CID and corresponding pub address in the published list, and verifies that the chip controls the correct pub address by means of a challenge-response scheme. Even though for blockchain or SSI interactions, a completely new wallet with new pub/priv keypair is generated, the pub/priv key of the CID is used when the authenticity of the chip is checked by means of a challenge response scheme. Everything happens in the client app (2021: iOS or Android; and the client code is open source), where there is no communication with Tangem, so Tangem is not able to see any activity conducted by this CID in an authenticity check. The CID and corresponding key pairs are not used in any other interaction. A new wallet with new pub/private key pair is generated on chip, with these keys being used for any transactions, signing, etc.

Q: With the chip firmware being proprietary, how can we be sure that the newly generated private keys for new wallets are not still linked somehow to the cards CID? A: The firmware is audited by Kudelski and can be verified with a published hash. TBD: How can it be verified, when and by whom? If the firmware is not open source, then somebody has to draw a hash from it in an authorized situation. However, Tangem cards are EAL6+ and FIDO2 certified.

On the issue of Rotation: {TBW prio 2}

Q: DHTs are not an immutable linear chronology oracle, which is the heart of the actual security problem. You claim KERI solves the security problem with DHTs?!

The immutable linear chronology is provided by the key event log (KEL) data structure itself. Getting a full copy is all you need. When retrieving a KEL over a network, then as you say a witness can prune some amount of the latest events, but every witness would have to be compromised for that to be undetectable.

If parties are so concerned, they could establish a large collectivised set of witnesses that sign and distribute all key events presented to this network (this would essentially be a Proof of Authority/federated blockchain but would require (configurable)% compromise for undetectable pruning of recent history. Only PoA/federated because the witness sets are designated by the controllers, so you could not just use arbitrary witnesses who join and leave the network at leisure (afaik).

The difference between the chain and the DHT is that not all DHT nodes act as witnesses for all KELs in the system (in the sense that they don't provide receipts for every KEL and aren't referenced in the witness sets of every KEL), but they could all (or at least the ones holding the KEL you seek) still provide availability for KELs and thus would have to all be compromised in order to hide a recent-history-pruning, only one has to transmit the new/complete version to prove all the other versions as being old/incomplete.

(CharlesCunningham)

The point of KERI is to encapsulate all the guarantees within KELs nothing else is needed. DHT is just for resolution process to find a place from where I can get it. This place can change as you like I could even get it in p2p interaction from someone else. DHT seems to be the most reasonable way to build solid infrastructure for resolution process but none of the nodes can actually inject or tamper KELs so you don’t have to trust them or get any guarantees from them. Since if the node will miss behave it is very easy to detect that.

(RobertMitwicki)

Q: You are arguing KERI affords greater security than a decentralized linear event system like Bitcoin?

…you would be fundamentally arguing that you can record a singular, immutable linear event history more securely than Bitcoin, and I see nothing in KERI that would indicate that.

Read the answer to this first.

If you read Szabo’s paper on threshold structures, you get security of the same type when ever you use a threshold structure, be it MFA, Multi-Sig, or Distributed consensus. They all are using a combination of multiple relatively weak attack surfaces that must be simultaneously compromised for a successful attack. So multiplying simultaneous weak surfaces = functional equivalent of a stronger attack surface. So when you look at KERI you see that the security is primarily due to cryptographic strength and the witnesses are not the primary source of security but merely secure one thing, that is the availability of the KEL for an identifier. Not the KEL itself. The KEL itself is secured by signatures.

From a Validator perspective their security is due to duplicity detection. Successful attack against duplicity detection requires an eclipse attack. Ledgers such as bitcoin are also susceptible to eclipse attacks. So in an apples to apples (resistance to eclipse attack) a KERI watcher network of comparable reach (1000’s of watchers) would have comparable resistance to an eclipse attack.

Q: Differences between blockchain-based security and KERI security

• Where KERI doesn’t need total ordering in its logs, blockchain do need that. What KERI needs is watchers that construct string of event in the relative order of reception of the KEL {TBW please explain or improve this: what is this, why is it important?}

• Another characteristic is that KERI identifiers are transferable and blockchain-based identifiers are not, they are bound to their ledger.

Q: How does FIFO prevent effective DOS attacks in Out-of-order KAACE?

An escrow cache of unverified out-of-order event provides an opportunity for malicious attackers to send forged event that may fill up the cache as a type of denial of service attack. For this reason escrow caches are typically FIFO (first-in-first-out) where older events are flushed to make room for newer events. Paragraph 11.3.1 Question: how does FIFO prevent effective DOS attacks?

By loadbalancing the incoming messages. If you don't have any loadbalancing, the messages are going to be processed First In First Out. Only when an attacker has full bandwidth available to overload the buffer, they could frustrate the process to get honest messages in. As soon as you’re able to balance the receipt of messages in the buffer, you’ll be able to get the right messages (from honest senders) through. (@henkvancann)