A Defense-in-Depth Approach: Notes on Sygma Security
Cross-chain bridges are amongst the most targeted applications in crypto, as they inevitably represent a decentralization bottleneck compared to the chains they connect. At the same time, bridges concentrate high volumes of digital assets that flow through them.
Moreover, the underlying “lock-mint-burn” method requires bridge contracts to custody assets worth billions of dollars. With such conditions in play, it’s worth outlining our (high-level) approach to security.
Unpacking Sygma’s security model
Sygma takes a multi-layered approach to defense rather than relying on any single measure. In addition to existing on-chain security ensured by Sygma’s audited smart contracts, we introduce a new off-chain defense layer backed by the cutting-edge cryptography of multi-party computation (MPC) and threshold signatures schemes (TSS).
This article details the security model of the latest version of Sygma relayer nodes. The section below outlines the overall security design of the selected MPC protocol and how it combines with existing on-chain contracts. We also discuss possible attack vectors and how we mitigate them. Let’s dive in!
Security design
Secure MPC represents a powerful next step in digital asset security because it eliminates the risks of a single point of compromise. It enables multiple parties to perform a distributed computation on their secret inputs without revealing anything but the output.
This concept has been thoroughly studied by academia for decades, but it’s only thanks to recent advancements in communication and computation technology that make it viable for real-world applications.
An area of MPC, called threshold cryptography, facilitates the distribution of a secret key to multiple parties, introducing redundancy into the security of assets management. It enables a set of parties to perform certain cryptographic operations while none of them holds a full secret key. Instead, the key is split across the parties, and it can be used only when a subset of parties, the size of which is larger than a certain threshold, combines their key shares.
In our architecture, we adopt the multiparty threshold scheme for the elliptic curve digital signature algorithm (ECDSA), which is used in many blockchains. Namely, the protocol used is the latest addition to the recognized family of protocols by Gennaro and Goldfeder.
The protocol
The chosen protocol is constructed from simple yet robust cryptographic building blocks. One of them is the technique of cryptographic secret sharing. In secret sharing, secret data can be shared among N parties such that any subset of at least T + 1 parties can reconstruct the secret, but the subsets with T and fewer parties cannot learn anything about the secret.
To ensure parties act honestly and follow the algorithm exactly, the protocol also employs various zero-knowledge proofs. This can vary from the simplest hashes comparison to more involved checks that require parties to share common reference parameters. As a result, as long as an attacker hasn’t corrupted more than T parties, there is nothing else they can do besides simply failing a computation.
But to make the corruption of parties infeasible in the first place, the protocol also comes with a proactive security guarantee. Namely, the key refresh operation aims to prevent an attacker from consecutively compromising all systems and ultimately recover the full private key. It would run at regular intervals while maintaining access to the funds locked under the same public key.
Finally, it won’t be possible for hackers to continually fail computation (e.g., to perform DoS or Ransom attacks) and stay uncovered. The abort identification feature of the protocol guarantees that any party that misbehaves could be identified and held accountable.
The chain
Another cornerstone of our security design is minimizing the attack surface by limiting the number of moving parts and keeping them close and tight. Ultimately, no matter how robust the specific protocols are, the overall security of the system will be determined by its weakest link.
With this in mind, the only other assumption that Sygma’s defense model relies on is the security of the blockchains it connects to.
Each request processed by Sygma will first go through a source chain contract to be verified and registered as a proposal. The event emitted by the chain will then trigger off-chain relayers to jointly compute the threshold signature for the message they observed on-chain. This signature serves as a one-time key allowing only that particular proposal to be further processed on the destination chain.
Attack mitigation strategy
To fully protect digital assets, it’s important to understand how cybercriminals typically compromise them. Fortunately, threshold cryptography is not a new concept, and its security and possible threat models have been studied for many years. This leaves us with an exhaustive list of possible attack vectors and methods of defending.
These attack vectors include:
- Private keys
- Communication channels
- Weak cryptographic parameters
- Implementation issues & bugs
Private keys
Private keys are one of the most attractive targets for hackers since, when stolen, they enable the holder to drain all assets instantly. Thanks to MPC, however, there is no single place to exfiltrate a full private key. This makes attacking such systems substantially more complicated but not impossible.
Malicious actors may instead attempt to exploit the operational complexity of such protocols and break their security guarantees by collecting sensitive information bit by bit.
Consider the nonce attack, where the adversary obtains some “leakage” information on the random string that the signers will use for generating signatures. This is solved by enforcing a specific “range policy” on all secret data so that even when leaked, attackers won’t be able to take advantage of it.
The way to “brute force” threshold cryptosystems is for attackers to take control over the majority of the committee. This is similar to 51% Attacks on Proof-of-Work (PoW) blockchains, with the exception that the amount of nodes to corrupt is defined by Sygma, i.e., threshold parameter T. It can be as high as 90% or even 100%. But to ensure that the network will stay functional when some parties unexpectedly go offline, we leave it at around 80%.
Moreover, while attacks on PoW (or PoS) require having a majority of resources (computational or financial), attackers that wish to forge threshold signatures can only do it after stealing a majority of key shares. This is especially problematic as these shares are subject to refreshment regularly under our proactive security guarantee. In other words, attackers have no choice but to corrupt all parties in a short period, or their hack will flop.
Last but not least is the possibility that the parties themselves will decide to collude if they find it economically more attractive than remaining honest, i.e., rogue parties.
Currently, Sygma has no incentivization model and acts as the trusted federation. Legal entities that run relayer nodes have no extra incentive to be honest besides what they publicly claim.
This can change in the future, but for now, we are taking more of a pessimistic defense approach. Even if all other parties — besides Sygma — collude, they still won’t have a majority of power in the network.
This is achieved by extending the standard threshold scheme with a notion of weight. Namely, the key shares are distributed in such proportion that the number of shares owned by all entities other than Sygma is less than T — while each entity individually also holds less than T shares. The latter requirement is needed to prevent Sygma from becoming a single point of failure and a primary target for attackers.
Communication channels
Properly secured communication channels are essential for the fault tolerance of MPC protocols. A formal safety proof of the network’s communication model requires the following two properties to be satisfied: validity, so that messages intended by an honest sender are received by all parties, and consistency so that all parties receive the same value even when the sender is malicious.
If these guarantees are violated, a whole class of attacks suddenly becomes possible. By using some crafty methods, attackers place themselves between two nodes that are exchanging data. This is such that every piece of data that should pass only between two original hosts passes through the attacking host. Such an attack can remain undetected for a long time until the attacker decides to use their position to take malicious action. We call them Man in the Middle attacks.
To ensure secure communication between relaying nodes, we follow the simple but robust practice of echoing, also known as echo broadcast. Once messages from all known parties are received, each relayer hashes these messages along with their ones and sends a hash as an acknowledgment. Assuming that all parties receive consistent messages, hashes will end up identical, and broadcast safety will be proven.
When no other options to exploit the system are found, attackers (say they were able to corrupt one party or place themselves in between communication channels) may decide to maliciously block computation from ever finishing and thus render the cross-chain infrastructure unusable, i.e., Denial of Service attack.
They may even hope to bargain for a ransom from the network. Either of these, however, won’t work due to the protocol’s accountability guarantees. Any computation failure can be connected to the party that caused it. If enough of these occur, the party’s reputation drops, and it will be blocked from further participation.
Weak cryptographic parameters
One of the less obvious but nevertheless critical considerations is properly configured cryptographic parameters. These determine how hard it would be to brute-force the system.
For example, it is possible to recover a secret share in 256 trials if the size of the prime number used to prove the consistency of these shares is equal to 1. However, when the proper value is used (1024), we can rest assured that no existing computer today could crack the key.
When choosing cryptographic parameters, we follow industry conventions and recommendations from the protocol designers. We also pay attention to the development of new hardware, in which case we will increase these parameters as needed.
Implementation issues and bugs
Even when a protocol has been theoretically proven on paper, libraries that implement it can still suffer from various implementation flaws. Attackers may find ways to exploit logical vulnerabilities enabled by the extra layers of complexity in the codebase or hosting infrastructure.
Consider, for example, a CVE-2020–12118 vulnerability. Here, the implementer missed placing the zero-knowledge proof verification. This bug could have made it possible for attackers to compromise parties in the network by crafting malicious messages which otherwise would have been detected. Our mitigation strategy for these consists of multiple audits, open-sourcing software for public examination, and a bug bounty program.
The implementation of the threshold cryptosystem protocol is bnb-chain/tss-lib, which was audited by Kudelski Security (report). The latest audit of Sygma relayers and smart contracts was conducted by Haechi Audit, and the report is available here.
When partnering with external auditors, we search for partners with concrete experience with the protocol to-be-audited and partners who specialize in auditing similar codebases. We also perform regular internal audits and cross-team reviews.
At Sygma, we firmly believe that open-sourcing software is essential for its security. It facilitates a collaborative effort to identify potential weaknesses in the software and networks so they can be remediated before being exploited by hackers. Of course, being open source can hint at ways to mount new attacks, but eventually, our open-source code will become bulletproof and time-tested through peer audits and community review.
Continuous improvement
Sygma will continue to maintain and improve the security levels of our software in accordance with the policies outlined in this document. Our researchers are constantly looking for ways to further strengthen the security of Sygma. We strive to continually refine our architectures and develop services that are progressively stronger.
About Sygma
Sygma is a community-driven interoperability project. Sygma makes it possible to deploy cross-chain with minimal effort and realize new use cases via its versatile, modular protocol. With Sygma, developers can leverage a secure cross-chain communication layer to extend their applications across EVM, Substrate, and beyond.
Get involved👋
We’re always looking for contributors, and Sygma’s modular architecture is designed to foster contributions and extensions. Please check out our documentation or GitHub to get started.
Sygma Builders Program🛠️
We’ve launched a builder program to provide technical support and monetary incentives for builders. Full details can be found 👉here.
