Document our security assumptions
This commit is contained in:
parent
4658dcb8f1
commit
70eddbee6e
|
@ -0,0 +1,122 @@
|
||||||
|
# Security Assumptions
|
||||||
|
|
||||||
|
This page details various assumptions that Wormhole relies on for security and availability. Many of these are
|
||||||
|
universally applicable to different decentralized protocols.
|
||||||
|
|
||||||
|
This document assumes familiarity with Wormhole concepts like VAAs, lockups and transfers.
|
||||||
|
|
||||||
|
## Gossip network availability
|
||||||
|
|
||||||
|
Wormhole's peer-to-peer gossip network relies on the [go-libp2p](https://github.com/libp2p/go-libp2p) and
|
||||||
|
[go-libp2p-pubsub](https://github.com/libp2p/go-libp2p-pubsub) library. libp2p is a very popular library used by many
|
||||||
|
major decentralized networks like IPFS and Ethereum 2.0. Nevertheless, like any distributed protocol, it may be
|
||||||
|
susceptible to various denial-of-service attacks that may cause message loss or overwhelm individual nodes.
|
||||||
|
|
||||||
|
We do _not_ rely on libp2p for security, only for availability. libp2p's channels are encrypted and authenticated by
|
||||||
|
default, but we do not rely on that property. A compromise of libp2p transport security could, at worst, result in
|
||||||
|
denial of service attacks on the gossip network or individual nodes.
|
||||||
|
|
||||||
|
Gossip network unavailability can result in transfers getting temporarily stuck, but never permanently. Nodes will
|
||||||
|
periodically attempt to retransmit signatures for VAAs which failed to reach consensus in order to mitigate short-term
|
||||||
|
network outages. Longer network outages, leading to eventual VAA retransmission timeouts, as well as correlated crashes
|
||||||
|
of a superminority of nodes, may result in lockups being dropped.
|
||||||
|
|
||||||
|
The mitigation for this is the PokeVAA mechanism on Solana or chain replay for other chains. On Solana, a user can
|
||||||
|
request retransmission of their lockup, resulting in re-observation by nodes and another round of consensus - and manual
|
||||||
|
chain replay by the nodes. During chain replay, nodes will re-process events from connected chains up from a given block
|
||||||
|
height, check whether a VAA has already been submitted to Solana, and initiate a round of consensus for missed lockups.
|
||||||
|
|
||||||
|
This carries no risk and can be be done any number of times because VAAs are fully deterministic and idempotent - any
|
||||||
|
given lockup will always result in the same VAA body hash. All connected chains keep a permanent record of whether a
|
||||||
|
given VAA body - identified by its hash - has already been executed, therefore, VAAs can safely undergo multiple rounds
|
||||||
|
of consensus until they are executed on all chains.
|
||||||
|
|
||||||
|
The bridge does not yet implement chain replay (see https://github.com/certusone/wormhole/issues/123). Network outages
|
||||||
|
can therefore result in stuck transfers from chains other than Solana in the case of a prolonged network outage. It
|
||||||
|
would be possible to retroactively recover locked funds after chain replay has been implemented.
|
||||||
|
|
||||||
|
## Chain consistency and finality
|
||||||
|
|
||||||
|
The Wormhole network always observes _external events_ and never initiates them on its own. It relies on the connected
|
||||||
|
chain's consensus, security and finality properties. In the case of guardian set updates, it relies on off-chain
|
||||||
|
operator consensus in the same way.
|
||||||
|
|
||||||
|
A non-exhaustive list of external chain properties Wormhole relies on:
|
||||||
|
|
||||||
|
- It can be assumed that at some point, transactions are final and cannot be rolled back.
|
||||||
|
- A given transaction is only included/executed once in a single block, resulting in a determistic VAA body.
|
||||||
|
- Account data and state is permanent, by default or through a mechanism like Solana's rent exemptions.
|
||||||
|
- No equivocation - there is only one valid block at a given height.
|
||||||
|
|
||||||
|
## On-chain spam prevention
|
||||||
|
|
||||||
|
We assume that all connected chains use a fee or similar mechanism to prevent an attacker from overwhelming the network,
|
||||||
|
and that Wormhole's processing capacity is greater than the sum of the capacity of all connected chains.
|
||||||
|
|
||||||
|
Solana has ridiculous processing capacity and can process transactions at a greater rate than what its websocket
|
||||||
|
subscription interface, the agent, or the Wormhole itself could handle. This is partially mitigated by the fee that the
|
||||||
|
Wormhole contracts charge in excess of the (very cheap) transaction fee, but a sufficiently incentived attacker could
|
||||||
|
still execute a sustained attack by simply paying said fee.
|
||||||
|
|
||||||
|
A possible future improvement would be dynamic fees on the Solana side, but this is currently blocked by runtime
|
||||||
|
limitations (see https://github.com/certusone/wormhole/issues/125). Even with dynamic fees, raising the fees beyond the
|
||||||
|
amount that a reasonable user would pay may already constitute a successful attack against the protocol.
|
||||||
|
|
||||||
|
DDoS attacks on decentralized protocols are a tricky thing in general, and mostly a matter of game theory/incentives.
|
||||||
|
Defense strategies are dynamic and evolve as the ecosystem grows. We therefore exclude such attacks from the current
|
||||||
|
Wormhole threat model. The assumption is that the incentive to execute such an attack is less than the cost in fees and
|
||||||
|
the legal/liability risks an attacker would incur, and that the costs to sustain the attack would be greater than simply
|
||||||
|
attacking the connected chains directly.
|
||||||
|
|
||||||
|
## Guardian incentive alignment
|
||||||
|
|
||||||
|
Wormhole is a decentralized PoA bridge. Its game-theoretical security relies on hand-picked operators whose incentives
|
||||||
|
strongly align with Solana ecosystem - large token holders, ecosystem projects, top validators and similar, who would
|
||||||
|
risk damage to their reputation, token values, and ecosystem growth by attacking the network or neglecting their duties.
|
||||||
|
|
||||||
|
We assume that at the present time, such incentive alignment is easy to bootstrap and get right than a separate chain,
|
||||||
|
which requires carefully-designed token economy and slashing criteria. In particular, it attracts operators who care
|
||||||
|
about the ecosystem beyond short-term validation rewards, resulting in a high-quality, resilient guardian set.
|
||||||
|
|
||||||
|
As the project grows, there's a number of potential improvements to consider other to a staking token, including
|
||||||
|
the [Balsa](https://docs.google.com/document/d/1sCgxHIOrVHAqrt4NWkUJXxQvpSxq6DyZrkf4IR-R-YM/edit) insurance pool
|
||||||
|
proposal and a DAO that offsets operational costs and rewards operators.
|
||||||
|
|
||||||
|
## Uncompromised hosts
|
||||||
|
|
||||||
|
This should go without saying - we assume that an adversary cannot read or write host memory, execute code, or otherwise
|
||||||
|
compromise the running host operating system or platform while or after the node is running.
|
||||||
|
|
||||||
|
Contrary to popular belief, hardware security modules do _not_ significantly change the risks associated with host
|
||||||
|
compromise when dealing with cryptocurrency keys. A compromised host could easily abuse the HSM as a signing oracle,
|
||||||
|
causing irreversible damage with a single signature. It merely complicates the attack, but not in a major way.
|
||||||
|
|
||||||
|
For some use cases, like PoS validation, the risk of host compromise can be fully mitigated by running a smart HSM like
|
||||||
|
[SignOS](https://certus.one/sign-os). In these cases, the smart HSM can parse the signature payload and apply
|
||||||
|
constraints like "a given block height may only be signed once", which can be independently verified in a secure
|
||||||
|
enclave. In the case of on an oracle like Wormhole, this constraint is "only finalized events may be certified", which
|
||||||
|
is impossible to verify without verifying block headers. Therefore, in the case of Wormhole, the entire Wormhole
|
||||||
|
instance would have to run inside a smart HSM, including light clients for the chains it supports.
|
||||||
|
|
||||||
|
## Third-party libraries
|
||||||
|
|
||||||
|
Like any modern software project, we rely on a number of external libraries. We applied best practices in dealing with
|
||||||
|
such third party dependencies, including minimizing their number, avoiding binary dependencies, and using lockfiles to
|
||||||
|
pin dependencies to exact versions and hashes to avoid distribution-level compromises. We assume that the third-party
|
||||||
|
libraries we use are safe and do not contain backdoors.
|
||||||
|
|
||||||
|
Go's supply chain is particularly hardened against such compromises thanks to the [public go.sum
|
||||||
|
database](https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md).
|
||||||
|
|
||||||
|
For cryptography in the node software, we exclusively rely on high-level interfaces in Go's standard library - which is
|
||||||
|
known for its robustness - and go-ethereum, both of which have been exhaustively audited.
|
||||||
|
|
||||||
|
## Safe handling of crashes in the Solana eBPF VM
|
||||||
|
|
||||||
|
Due to the instruction count limitations in the Solana runtime, the Solana contracts makes liberal use of unsafe blocks
|
||||||
|
to serialize and deserialize data without incurring the overhead of a memory-safe approach.
|
||||||
|
|
||||||
|
This follows current best practices for Solana contract development. It assumes that invalid operations or out-of-bounds
|
||||||
|
accesses will always cause a crash and be caught by the bytecode interpreter, and safely halt contract execution like
|
||||||
|
any other error during contract execution would.
|
||||||
|
|
|
@ -1,20 +0,0 @@
|
||||||
# Security Properties
|
|
||||||
|
|
||||||
- Wormhole is a decentralized proof-of-authority system. All nodes - called guardians - have equal voting power.
|
|
||||||
|
|
||||||
A 2/3+ majority is required for guardians to achieve consensus.
|
|
||||||
|
|
||||||
The guardian set will consist of Solana validators, reputable community members, ecosystem stake holders
|
|
||||||
and other parties whose incentives strongly align with Solana and Solana ecosystem projects like Serum.
|
|
||||||
|
|
||||||
- We believe that this model is easier to implement and reason about and more likely to result in incentive alignment
|
|
||||||
with Solana ecosystem stakeholders than launching a separate PoS chain.
|
|
||||||
|
|
||||||
- It is possible to add staking in the future.
|
|
||||||
|
|
||||||
- Wormhole is leaderless. All nodes perform the same computation upon observing an event.
|
|
||||||
|
|
||||||
- Wormhole acts as a decentralized cross-chain oracle, observing finalized transactions on one
|
|
||||||
chain and producing a joint signed statement of all guardians on another chain.
|
|
||||||
|
|
||||||
<!-- TODO: to be continued
|
|
|
@ -26,7 +26,9 @@ message GuardianSetUpdate {
|
||||||
uint32 current_set_index = 1;
|
uint32 current_set_index = 1;
|
||||||
|
|
||||||
// UNIX timestamp (s) of the VAA to be created. The timestamp is informational and will be part
|
// UNIX timestamp (s) of the VAA to be created. The timestamp is informational and will be part
|
||||||
// of the VAA submitted to the chain. It's part of the VAA digest and has to be identical across nodes.
|
// of the VAA submitted to the chain. It's part of the VAA digest and has to be identical across nodes and
|
||||||
|
// is critical for replay protection - a given event may only ever be observed with the same timestamp,
|
||||||
|
// otherwise, it may be possible to execute it multiple times.
|
||||||
//
|
//
|
||||||
// For lockups, the timestamp identifies the block that the lockup belongs to. For guardian set updates,
|
// For lockups, the timestamp identifies the block that the lockup belongs to. For guardian set updates,
|
||||||
// we create the VAA manually. Best practice is to pick a timestamp which roughly matches the expected
|
// we create the VAA manually. Best practice is to pick a timestamp which roughly matches the expected
|
||||||
|
|
Loading…
Reference in New Issue