Security of KERI Software/Hardware Infrastructure.

[SmithSamuelM]

Some comments on KERI security guarantees with respect to the root-of-trust in a SCID (self-certifying-identifeir).

One can say that as long as KERI signing and verification software runs in a trusted execution environment such as SGX, TrustZone, HSM, security controller etc.. that is evaluated to be “as secure as the key storage and RoT technology” then one can make the claim that with KERI as long as your secrets remain secret then the rest of the system is as secure as the crypto strength. How you protect your secrets is application dependent. However, one may use the threshold structure of KERI to enable secure signing and verification without TEEs.

Two Roots-of-Trust

The verifier's software/hardware needs to be as secure from the respect of the verifier as the root-of-trust of the signer. But it depends on what the "verifier" is. A verifier may be a single device or employ a network of watchers. Indeed KERI was designed specifically so that a pool of watchers may be employed for the "verifier" or validator function. When a pool of watchers is employed then that pool may be designed to be as secure as needed but without using TEEs (see detailed explanation below). Moreover because KERI splits the system into two sides, each side has two two distinct roots-of-trust each of a different kind. Because the verifier side is the easiest to manage, the KERI WP does not spend much time on it. The security consideration of both hardware and software on both sides should be considered.

To elaborate, the promulgation side (the controller) uses a root-of-trust that is a SCID (self certifying identifier) the security is based on the controller's private keys. The confirmation side ( verifier) has a different distinct root-of-trust which is based on the verifier's hardware/software. The verifier's root-of-trust is independent of the controller's. It is not a function of the key management of the controller. However both the controller's side and the verifier's side can multiply their attack surfaces such that relatively weak software/hardware on either side is compensated for with distributed consensus. So in the special case when the verifier is a single device or uses a single watcher then the watcher/verifier may very well benefit from using a TEE to have the same degree of security as the controller when the controller is using a TEE. But if the verifier is using a pool of watchers then the watchers as a pool can be as secure as a controller's TEE without any of the watchers using a TEE (see my further qualifications to this statement below).

Threshold Structure Security vs. TEE Security

One can have a long discussion about how secure a distributed consensus pool may be. But when comparing apples (key management and execution environment security) and oranges (distributed consensus security) approaches to security its hard to say that the security of a distributed consensus algorithm is necessarily less secure than the key management infrasture root-of-trust of any of its nodes. Although as a general rule, in an apples to apples comparisons, more complex is less secure.

This early influential paper by Nick Szabo does a good job of explaining why the two types of security are complementary and that the whole is greater than the sum of the parts.

Advances in Distributed Security

Szabo describes the concept of a "threshold structure", which underlies the ideas in the security guarantees of multi-signatures, distributed consensus, and MFA to name a few. KERI itself employs threshold structures namely, multi-sig and distributed consensus, and assumes that the key management is using best practices such as MFA.

What a threshold structure for security does for us is that we can have weaker key management or execution environment infrastructure individually but use a threshold structure to multiply our attack surface to achieve greater overall security. In other words overall security is greater than any of the individual parts on its own. For example, in MFA the combination of something you have and something you know is much more secure than either of the factors by themselves.

As is well known, a distributed consensus algorithm is a provable algorithm using a set of nodes where the algorithm provides a security guarantee that is greater than the security guarantee of any of its constituent nodes. It makes a guarantee that in spite of a compromise of F of the 3F+1 nodes, the ledger written by the pool as a whole is still secure. So it's improving security by multiplying the attack surface. This may be more or less complex depending on how one defines complexity.

To restate, the value of Byzantine Fault Tolerant algorithms is that one can arbitrarily increase the degree of difficulty to an attacker by multiplying the attack surface using a distributed network of nodes with sufficient non-common mode failure vulnerabilities.

This applies to KERI as well. The witnesses and watchers independently multiply the attack surfaces of the promulgator and the confirmer (validator/verifier) such that each witness or watcher may be relatively insecure but the system as a whole is highly secure. A better way of re-stating the topic statement is that:

Through threshold structures, KERI enables the promulgator to to make its system no less secure than the security of its secrets and enables the confirmer (validator) to make its security at least as secure as the security of the promulgator.

Obviously in resource constrained IoT applications there are limits to distributed consensus.

Nonetheless, the point of KERI is to capture the goodness of distributed consensus without the cost, latency, and throughput limitations of conventional blockchain distributed consensus algorithms for crypto currencies. The most important feature of a crypto currency is that it must be double spend proof. Because KERI's key event operations are idempotent they do not need to be double spend proofed, so we can greatly simplify the distributed consensus algorithm in KERI. Which makes KERI relatively more attractive for IoT applications by comparison.

As a result of the relaxation of double spend proofing, KERI is able to break the distributed consensus algorithm into two halves and simplify it in the process. As mentioned above the two halves are the promulgation half and the confirmation half.

The promulgation half is under the control of the holder of the private keys. The controller of the private keys has sole control over the security guarantees of the signed key events. and the promulgation of those events. The controller is not dependent on any other entity for its security. The controller is free to make its promulgation system (witness set) arbitrarily as secure as it desires. Although there is no point in making it more secure than its root-of-trust in its key management. The promulgation infrastructure is simply receipting. The receipted events are then broadcast. No attacker can forge any signed event without compromising the signing infrastructure. In indirect mode this means more than F of the witnesses. And when using multi-sig K of the N signatories. The worst an attacker can do without compromising the signing infrastructure of F of the witnesses, is to DDOS or delete the broadcast. This is a well delimited and well understand type of attack with well understood mitigations. It's not a serious impediment.

The confirmation half is under the control of the validator (verifier). The validator is confirming events promulgated by the controller. The validator is free to design and implement the security guarantees of its confirmation system (watchers) to be as secure as it needs and is not dependent on any external entity for that. The verification happens in the edge so an attacker must attack a multitude of edge verifiers (watchers) with little net gain. This multiplies the attack surface for the attacker. Mitigation mechanism for attacks on verifier hardware/software are also well known. Given that verification is largely a fixed operation in software, the verification hardware/software can be deployed by the verifier in a manner that is not predictable by any attacker. Once deployed the attacker must individually exploit each edge verifier (watcher). But multiplying the attack surface with multiple watchers, each validator may arbitrarily increase the difficulty of attack without having to use TEEs for its watchers.

By splitting the attack surfaces into two independent sides. The controller (promulgation side) and the validator (confirmation side) may independently set their security levels by multiplying their own attack surfaces separably.

KERI by design puts verification at the edge. The weakest case is an application where there is only one verifier/watcher, such as in a mobile device under the physical control of the verifier. But even in this case verification at the edge means the attacker is fighting an asymmetric war where the asymmetry is in the favor of the verifier. An attacker may only compromise one device at a time for a lot of effort. That does not mean that there are not common mode exploits such as attacking the crypto library on GitHub that the verifier software uses.

In use cases such as a remote payment card reading device, or some other like application where the sole verifier is a known high value target, then the verifying device benefits from being a TEE.

KERI design enables the confirmer (validator) to make a trade-off. A given verifier could be secured by using a verifiable attestable HSM (TEE) to perform the end verification operations on the KERI events i.e. the watcher. This provides assurance to the validator that the cryptographic signatures are verified correctly and that the verification software/firmware on the watcher has not been tampered with. Or the validator may choose to use a threshold structure to secure the signature verifications of its watchers through a distributed consensus pool of confirming nodes that each perform the signature verification and then compare results. Or the validator could do a combination where each watcher verifier is using an HSM for signature verification so that fewer verifiers are needed because each verifier is more secure due to its HSM. Likewise the promulgation (controller) can make similar trade-offs for its witnesses. More witnesses without HSM/TEE for signature verification and receipt (signature generation) or fewer with HSM/TEE. But most importantly the separation of control via the splitting up of promulgation and confirmation enables each to design and implement according to their desired guarantees of security.

As a use case, the end verifiability of KERI opens up an opportunity for HSMs for signature verification. Currently there are many low cost hardware devices (HSMs) such as a Ledger Nano, UbiKey, Trezor etc. The provide signature generation. But not so for signature verification. With KERI there may be applications especially in IoT where verifiable attestable HSMs may be used for event signature verification.

The trusted computing group recently released a standard for low cost HSM chips that would be applicable to HSM for signature verification for end verifiers:

https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf

This combined with the IETF standard for remote attestation:

https://datatracker.ietf.org/wg/rats/about/

Would enable a new class of HSM for end verification where a validator could query the HSM and be assured via a signed attestation that its signature verification firmware has not been tampered with.

Typically mobile phone devices could be used as a type of general purpose HSM for KERI event signature verification but a dedicated USB device that only does verification could provide a better security trade off.

Verifier Assumptions

KERI makes some assumptions about the verifier.

1) The software/hardware that is doing the verification is under the control of the verifier. 2) The verification hardware/software is not dependent on any external infrastructure to do the verification at the time of verification other than to receive a copy of the events. 3) The software/hardware that is verifying signatures has not been compromised. Singley when only one verifier/watcher or multiply above a threshold when a multiple of watchers.

If the software/hardware that is under the control of the verifier has been compromised then no cryptographic operations run by the verifier may be trusted by the verifier.

But Given 1) 2) and 3), the worst than an external attacker can do is a DDOS or delete attack to prevent the validator from seeing the events. Not forge an event and trick a validator into accepting it. Duplicity detection, which protects, not against an external attacker, but against a malicious controller does require access to watchers that are also recording duplicitous events. So this may be called external but its generic and the goal is to make it ambient such that a malicious controller may be easily detected.

One useful way of describing KEIR is that it is a decentralized key management infrastructure that is based on key change events that supports attestable key events and consensus based verification of key events.

With KERI security becomes largely a function of your own infrastructure such as key management and not some other entity's “trusted” internet infrastructure. Each controller of an identifier gets to pick their own infrastructure. This is a big advantage as it does away with the whole house of cards that are the “trusted entities” in DNS/CA.

It’s much easier to secure one's own keys well than to secure everyone else's internet computing infrastructure well.

[SmithSamuelM]

This discussion is captured in more detail in the following whitepaper:
https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf