The Security of the Kima Blockchain
The Kima platform is designed with the most advanced security protocols and instruments available today. It stands apart in its design due to its use of two security mechanisms: threshold signatures and trusted execution environments. Kima wardens control the asset pools on the destination chain through the use of Threshold signature schemes, and security is further strengthened by running the wardens inside a Trusted Execution Environment.
Threshold Signatures
Threshold signature schemes (TSSs) allow a group of participants (“cosigners”) to securely generate and control the secret signing key for a digital signature scheme, such that a certain threshold (e.g., 7-out-of-10) cosigners must participate in the signing protocol in order to generate a signature. Specifically, a threshold signature scheme consists of two protocols (1) Distributed Key Generation and (2) Distributed Signature Generation.
Distributed Key Generation Protocol The Distributed Key Generation protocol creates private “key shares,” where each participant holds a single share and a single public verification key for a digital signature algorithm (either ECDSA, or ED25519).
Distributed Signature Generation Protocol The Distribute Signature protocol takes each participant’s key share and a (public) message and creates a digital signature on the message that will verify under the verification key created during the key-generation protocol.
Implementation of Protocols For a Threshold Signature Scheme The “threshold” property comes from the guarantee that there is a fixed threshold (e.g., t-out-of-n) such that an adversary who corrupts up to t-participants in the protocol (and learns their private key shares) learns nothing about the underlying secret key. In particular, an adversary who corrupts t or fewer participants cannot generate a new signature on any message.
Threshold Signature protocols can be extended to arbitrary authority structures. For instance, there could be a public set of n1 signers that have undergone KYC and a larger set n2 of anonymous signers that are chosen dynamically through Proof of Stake. The TSS could then be built so that it needs both t1 + 1 public signers AND t2 + 1 anonymous signers to participate in order for a statement to be signed. Any adversary then who does not control this learns nothing of the underlying secret key and is unable to forge signatures.
Furthermore, TSS protocols can use Proactive Secret Sharing¹ to redistribute shares of the secret key. This means that if an adversary is unable to learn the secret key before a redistribution, all the information it gained before the redistribution becomes useless after the redistribution. For instance, if we have a t-out-of-n sharing of the secret key, the adversary can corrupt t nodes before the redistribution and another t after, but will still not be able to learn the secret key. Proactive Secret Sharing strictly increases the security of the system, by improving protection against adversaries who corrupt multiple nodes over time.
Threshold signature schemes exist for ECDSA² and ED25519³. In addition to rigorous theoretical proofs of security, TSS schemes have been widely implemented. In fact, professionally audited, open-source TSS libraries are available from Axelar⁴, ZenGo⁵, ING bank⁶, Binance⁷, Thorchain⁸, Ren⁹, and Coinbase¹⁰. Collectively, these TSS implementations are currently used to custody billions of dollars worth of tokens across multiple blockchains. Although attacks are common in the DeFi space, there have been no reported attacks that have exploited a Threshold Signature Scheme.
Trusted Execution Environments
Trusted Execution Environments (TEEs) provide hardware-based security where secrets can be stored, and code can be executed in a secure and verifiable manner. The key properties of a TEE are:
Privacy. Data processed inside the TEE cannot be accessed by external programs, system administrators, or attackers who have physical access to the machines.
Transparency. TEEs can “attest” to the code they are executing, thus the output of a TEE can be publicly verified.
The most common TEE is Intel SGX¹¹ which is available on a wide variety of Intel CPUs¹². Microsoft Azure supports Intel SGX in its cloud instances¹³.
In the blockchain space, Intel SGX has been used to increase user privacy as well as improve security. On the privacy front, both the Secret Network¹⁴ and Oasis Cipher Paratime¹⁵ use Intel SGX to facilitate private smart contracts on Cosmos-based blockchains. On the security front, the Avalanche Bridge implements a 3-out-of-4 threshold signature scheme inside Intel SGX enclaves¹⁶. This does not improve the privacy of the bridge but instead reduces the trust in the (anonymous) bridge “wardens” by generating and storing each warden’s key-share inside an SGX enclave. Using this combination of TSS and SGX, the Avalanche Bridge wardens are custodians of more than $5.7B worth of assets on the Ethereum blockchain¹⁷.
To provide transaction privacy in a blockchain using committee-based consensus, each block producer can run their nodes inside an SGX enclave. Using Intel’s attestation feature, every block producer can verify that all the other committee members are running the authorized blockchain client inside an SGX enclave. The enclaves can generate key-pair(s) for a public-key encryption protocol that allows users to encrypt their transactions before sending them to a node. Upon receiving an encrypted transaction, the transaction can be decrypted and validated inside the SGX enclave. The security of SGX guarantees that even the block producers themselves cannot decrypt the encrypted transactions.
Although Intel SGX is very powerful, it is not a panacea – there have been several high-profile attacks against SGX enclaves¹⁸, and even in the absence of attacks, relying on Intel for security provides an unwanted and unnecessary point of centralization.
Kima does not rely on the security of Intel SGX to maintain its privacy or safeguard its assets. Instead, Kima uses SGX to complement the security of its system. Kima wardens run the threshold signature scheme inside an SGX enclave, thus the TSS key-shares are not directly accessible to the wardens or their system administrators. Instead, the key-shares are held inside SGX enclaves, and the entire multiparty key-generation and signing protocols are run inside the enclaves as well. This strictly improves the security of the underlying threshold signature scheme. In a t-out-of-n threshold signature scheme, security holds as long as no more than t wardens collude to subvert the protocol. When the TSS protocol is run inside SGX, to break security t + 1 would need to first break the security of SGX and then collude. Thus by implementing the threshold signature scheme inside an SGX enclave, Kima can significantly boost security with only a negligible loss in performance.
¹Joshua Baron, Karim El Defrawy, Joshua Lampkins, and Rafail Ostrovsky. Communication-optimal proactive secret sharing for dynamic groups. In International Conference on Applied Cryptography and Network Security, pages 23–41. Springer, 2015.
²Rosario Gennaro and Steven Goldfeder. One round threshold ECDSA with identifiable abort. IACR ePrint Archive, 2020.
³P. M. Hallam-Baker. Threshold signatures using Ed25519 and Ed448. Technical report, IETF, 2020.
⁴https://github.com/axelarnetwork/tofn
⁵https://github.com/ZenGo-X/multi-party-ecdsa
⁶https://github.com/ing-bank/threshold-signatures
⁷https://github.com/bnb-chain/tss-lib
⁸https://github.com/thorchain/thorchain-tss
⁹https://github.com/renproject/mpc
¹⁰https://github.com/coinbase/kryptology
¹¹Victor Costan and Srinivas Devadas. Intel SGX explained, 2016.
¹²https://github.com/ayeks/SGX-hardware
¹⁴https://scrt.network/graypaper
¹⁵https://github.com/oasisprotocol/cipher-paratime
¹⁶Conor Leary. Avalanche bridge: Secure cross-chain asset transfers using Intel SGX.https://medium.com/avalancheavax/avalanche-bridge-secure-cross-chain-asset-transfers-using-intel-sgx-b04f5a4c7ad1,2021.
¹⁷https://etherscan.io/address/0xe78388b4ce79068e89bf8aa7f218ef6b9ab0e9d0
¹⁸Alexander Nilsson, Pegah Nikbakht Bideh, and Joakim Brorsson. A survey of published attacks on Intel SGX. arXiv preprint arXiv:2006.13598, 2020.
Last updated
