github.com/Team-Kujira/tendermint@v0.34.24-indexer/spec/light-client/attacks/isolate-attackers_002_reviewed.md (about) 1 # Lightclient Attackers Isolation 2 3 Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules. 4 5 As Tendermint consensus and light client verification is safe under the assumption of more than 2/3 of correct voting power per block [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link], this implies that if there was an attack then [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link] was violated, that is, there is a block such that 6 7 - validators deviated from the protocol, and 8 - these validators represent more than 1/3 of the voting power in that block. 9 10 In the case of an [attack][node-based-attack-characterization], the lightclient [attack detection mechanism][detection] computes data, so called evidence [[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link], that can be used 11 12 - to proof that there has been attack [[TMBC-LC-EVIDENCE-DATA.1]][TMBC-LC-EVIDENCE-DATA-link] and 13 - as basis to find the actual nodes that deviated from the Tendermint protocol. 14 15 This specification considers how a full node in a Tendermint blockchain can isolate a set of attackers that launched the attack. The set should satisfy 16 17 - the set does not contain a correct validator 18 - the set contains validators that represent more than 1/3 of the voting power of a block that is still within the unbonding period 19 20 # Outline 21 22 After providing the [problem statement](#Part-I---Basics-and-Definition-of-the-Problem), we specify the [isolator function](#Part-II---Protocol) and close with the discussion about its [correctness](#Part-III---Completeness) which is based on computer-aided analysis of Tendermint Consensus. 23 24 # Part I - Basics and Definition of the Problem 25 26 For definitions of data structures used here, in particular LightBlocks [[LCV-DATA-LIGHTBLOCK.1]](https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-data-lightblock1), we refer to the specification of [Light Client Verification][verification]. 27 28 The specification of the [detection mechanism][detection] describes 29 30 - what is a light client attack, 31 - conditions under which the detector will detect a light client attack, 32 - and the format of the output data, called evidence, in the case an attack is detected. The format is defined in 33 [[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link] and looks as follows 34 35 ```go 36 type LightClientAttackEvidence struct { 37 ConflictingBlock LightBlock 38 CommonHeight int64 39 } 40 ``` 41 42 The isolator is a function that gets as input evidence `ev` 43 and a prefix of the blockchain `bc` at least up to height `ev.ConflictingBlock.Header.Height + 1`. The output is a set of *peerIDs* of validators. 44 45 We assume that the full node is synchronized with the blockchain and has reached the height `ev.ConflictingBlock.Header.Height + 1`. 46 47 #### **[LCAI-INV-Output.1]** 48 49 When an output is generated it satisfies the following properties: 50 51 - If 52 - `bc[CommonHeight].bfttime` is within the unbonding period w.r.t. the time at the full node, 53 - `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]` 54 - Validators in `ev.ConflictingBlock.Commit` represent more than 1/3 of the voting power in `bc[ev.CommonHeight].NextValidators` 55 - Then: The output is a set of validators in `bc[CommonHeight].NextValidators` that 56 - represent more than 1/3 of the voting power in `bc[ev.commonHeight].NextValidators` 57 - signed Tendermint consensus messages for height `ev.ConflictingBlock.Header.Height` by violating the Tendermint consensus protocol. 58 - Else: the empty set. 59 60 # Part II - Protocol 61 62 Here we discuss how to solve the problem of isolating misbehaving processes. We describe the function `isolateMisbehavingProcesses` as well as all the helping functions below. In [Part III](#part-III---Completeness), we discuss why the solution is complete based on result from analysis with automated tools. 63 64 ## Isolation 65 66 ### Outline 67 68 We first check whether the conflicting block can indeed be verified from the common height. We then first check whether it was a lunatic attack (violating validity). If this is not the case, we check for equivocation. If this also is not the case, we start the on-chain [accountability protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit). 69 70 #### **[LCAI-FUNC-MAIN.1]** 71 72 ```go 73 func isolateMisbehavingProcesses(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress { 74 75 reference := bc[ev.conflictingBlock.Header.Height].Header 76 ev_header := ev.conflictingBlock.Header 77 78 ref_commit := bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit // + 1 !! 79 ev_commit := ev.conflictingBlock.Commit 80 81 if violatesTMValidity(reference, ev_header) { 82 // lunatic light client attack 83 signatories := Signers(ev.ConflictingBlock.Commit) 84 bonded_vals := Addresses(bc[ev.CommonHeight].NextValidators) 85 return intersection(signatories,bonded_vals) 86 87 } 88 // If this point is reached the validator sets in reference and ev_header are identical 89 else if RoundOf(ref_commit) == RoundOf(ev_commit) { 90 // equivocation light client attack 91 return intersection(Signers(ref_commit), Signers(ev_commit)) 92 } 93 else { 94 // amnesia light client attack 95 return IsolateAmnesiaAttacker(ev, bc) 96 } 97 } 98 ``` 99 100 - Implementation comment 101 - If the full node has only reached height `ev.conflictingBlock.Header.Height` then `bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit` refers to the locally stored commit for this height. (This commit must be present by the precondition on `length(bc)`.) 102 - We check in the precondition that the unbonding period is not expired. However, since time moves on, before handing the validators over Cosmos SDK, the time needs to be checked again to satisfy the contract which requires that only bonded validators are reported. This passing of validators to the SDK is out of scope of this specification. 103 - Expected precondition 104 - `length(bc) >= ev.conflictingBlock.Header.Height` 105 - `ValidAndVerifiedUnbonding(bc[ev.CommonHeight], ev.ConflictingBlock) == SUCCESS` 106 - `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]` 107 - `ev.conflictingBlock` satisfies basic validation (in particular all signed messages in the Commit are from the same round) 108 - Expected postcondition 109 - [[FN-INV-Output.1]](#FN-INV-Output1) holds 110 - Error condition 111 - returns an error if precondition is violated. 112 113 ### Details of the Functions 114 115 #### **[LCAI-FUNC-VVU.1]** 116 117 ```go 118 func ValidAndVerifiedUnbonding(trusted LightBlock, untrusted LightBlock) Result 119 ``` 120 121 - Conditions are identical to [[LCV-FUNC-VALID.2]][LCV-FUNC-VALID.link] except the precondition "*trusted.Header.Time > now - trustingPeriod*" is substituted with 122 - `trusted.Header.Time > now - UnbondingPeriod` 123 124 #### **[LCAI-FUNC-NONVALID.1]** 125 126 ```go 127 func violatesTMValidity(ref Header, ev Header) boolean 128 ``` 129 130 - Implementation remarks 131 - checks whether the evidence header `ev` violates the validity property of Tendermint Consensus, by checking against a reference header 132 - Expected precondition 133 - `ref.Height == ev.Height` 134 - Expected postcondition 135 - returns evaluation of the following disjunction 136 **[LCAI-NONVALID-OUTPUT.1]** == 137 `ref.ValidatorsHash != ev.ValidatorsHash` or 138 `ref.NextValidatorsHash != ev.NextValidatorsHash` or 139 `ref.ConsensusHash != ev.ConsensusHash` or 140 `ref.AppHash != ev.AppHash` or 141 `ref.LastResultsHash != ev.LastResultsHash` 142 143 ```go 144 func IsolateAmnesiaAttacker(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress 145 ``` 146 147 - Implementation remarks 148 - This triggers the [query/response protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit). 149 - Expected postcondition 150 - returns attackers according to [LCAI-INV-Output.1]. 151 152 ```go 153 func RoundOf(commit Commit) []ValidatorAddress 154 ``` 155 156 - Expected precondition 157 - `commit` is well-formed. In particular all votes are from the same round `r`. 158 - Expected postcondition 159 - returns round `r` that is encoded in all the votes of the commit 160 - Error condition 161 - reports error if precondition is violated 162 163 ```go 164 func Signers(commit Commit) []ValidatorAddress 165 ``` 166 167 - Expected postcondition 168 - returns all validator addresses in `commit` 169 170 ```go 171 func Addresses(vals Validator[]) ValidatorAddress[] 172 ``` 173 174 - Expected postcondition 175 - returns all validator addresses in `vals` 176 177 # Part III - Completeness 178 179 As discussed in the beginning of this document, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules. 180 The main function `isolateMisbehavingProcesses` distinguishes three kinds of wrongly signed messages, namely, 181 182 - lunatic: signing invalid blocks 183 - equivocation: double-signing valid blocks in the same consensus round 184 - amnesia: signing conflicting blocks in different consensus rounds, without having seen a quorum of messages that would have allowed to do so. 185 186 The question is whether this captures all attacks. 187 First observe that the first check in `isolateMisbehavingProcesses` is `violatesTMValidity`. It takes care of lunatic attacks. If this check passes, that is, if `violatesTMValidity` returns `FALSE` this means that [[LCAI-NONVALID-OUTPUT.1]](#LCAI-FUNC-NONVALID1]) evaluates to false, which implies that `ref.ValidatorsHash = ev.ValidatorsHash`. Hence, after `violatesTMValidity`, all the involved validators are the ones from the blockchain. It is thus sufficient to analyze one instance of Tendermint consensus with a fixed group membership (set of validators). Also, as we have two different blocks for the same height, it is sufficient to consider two different valid consensus values, that is, binary consensus. 188 189 For this fixed group membership, we have analyzed the attacks using the TLA+ specification of [Tendermint Consensus in TLA+][tendermint-accountability]. We checked that indeed the only possible scenarios that can lead to violation of agreement are **equivocation** and **amnesia**. An independent study by Galois of the protocol based on [Ivy proofs](https://github.com/tendermint/spec/tree/master/ivy-proofs) led to the same conclusion. 190 191 # References 192 193 [[supervisor]] The specification of the light client supervisor. 194 195 [[verification]] The specification of the light client verification protocol. 196 197 [[detection]] The specification of the light client attack detection mechanism. 198 199 [[tendermint-accountability]]: TLA+ specification to check the types of attacks 200 201 [tendermint-accountability]: 202 https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md 203 204 [supervisor]: 205 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md 206 207 [verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md 208 209 [detection]: 210 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md 211 212 [LC-DATA-EVIDENCE-link]: 213 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#lc-data-evidence1 214 215 [TMBC-LC-EVIDENCE-DATA-link]: 216 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#tmbc-lc-evidence-data1 217 218 [node-based-attack-characterization]: 219 https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#node-based-characterization-of-attacks 220 221 [TMBC-FM-2THIRDS-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-fm-2thirds1 222 223 [LCV-FUNC-VALID.link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-func-valid2