From 725718df77cd6a505bf7b2674f5901387d4e2e2c Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Sun, 14 May 2023 11:40:08 +0300 Subject: [PATCH 01/13] wip re-registering-attack --- sips/re_registering_attack_protection.md | 84 ++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 sips/re_registering_attack_protection.md diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md new file mode 100644 index 0000000..49fbf5b --- /dev/null +++ b/sips/re_registering_attack_protection.md @@ -0,0 +1,84 @@ +| Author | Title | Category | Status | +|-----------------------------| ------------------------------- | -------- | ------------------- | +| Lior Rutenberg (@lior-blox) | SSV Register Cluster copied shares attack | Core | open-for-discussion | + +## Summary + +A copied shares attack can happen by an attacker registering valid shares to a valid validator by frontrunning a valid register cluster transaction or re-registering a removed validator. + +In both cases a validator will be running on SSV by a malicious user instead of the owner of the validator. + +#### Front-Running +A malicious attacker will front-run an honest user registering a validator. +The registration will pass as valid. +The attacker will pay fees for the validator to maintain the attack active. + +The honest user will need to exit the validator to make any change (remove/ change cluster). + +#### Re-registering attack +An attacker will detect a removed validator (removed from the SSV network) and will re-register it immediately, preventing the owner from moving the validator away. +The attacker will pay fees for the validator to maintain the attack active. + +The honest user will need to exit the validator immediately. + +## Rational & Design Goals +We need to protect users from having their validators being hijacked by malicious actors by ensuring that only the owner of the validator can register it to the SSV network. +This SIP proposes a solution using validator private key to sign on the address that making the registration and a nonce. +A nonce is required to prevent re-registering edge case where the removed validator address is compromised and the attacker can re-register it with the original address. +The BLS signature will be verified by the ssv nodes using the validator public key and making sure the nonce is higher than the last one. +The nonce will be on an account level and not a validator level to prevent the case where a validator is removed and re-registered by the same user. +It should be decided if it's needed to be stored on the contract or on the SSV nodes only. + + +## Specification +The specification is divided into 3 parts: +1. Changing the validator registration process to include the validator's signature on the address. +2. Changing the validator map keys in the contract to include address in addition to the public key. +3. Adding the signature verification to the SSV nodes upon validator registration. + + +### SSV Keys +SSV keys should input should include the validator's address and the last account nonce. +It will use the validator private key to sign on the address and the incremented nonce. +The output should include the signature and the incremented nonce in addition to the current output. + +### SSV Contract + +Changing the validator mapping to include the address in addition to the public key. + +From: +```solidity + struct Validator { + address owner; + bool active; + } + mapping(bytes32 => Validator) public validatorPKs; +``` +To: +```solidity + struct Validator { + bytes32 hashedOperators; + bool active; + } + mapping(bytes32 => Validator) public validatorPKs; + + //example of setting the mapping + validatorPKs[keccak256(abi.encodePacked(publicKey, msg.sender))] = Validator({hashedOperators: keccak256(operatorIds), active: true}); + + function registerValidator( + bytes calldata publicKey, + uint64[] memory operatorIds, + bytes calldata shares, + bytes calldata signature, //signature on the address and nonce + uint256 nonce, + uint256 amount, + Cluster memory cluster + ) + +``` +> Note: registerValidator function input parameters are not final and should consider gas fees optimisation. +> +> 1. Combined shares, signature and nonce to one bytes array. +> 2. Combined signature and nonce to one bytes array. +> 3. Keep the all separate. + From 3c78f37a68fe61330f885c3d7876571b7410de97 Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Sun, 14 May 2023 11:48:13 +0300 Subject: [PATCH 02/13] formatting --- all.md | 21 +++++++++++---------- core.md | 21 +++++++++++---------- sips/re_registering_attack_protection.md | 12 ++++++------ 3 files changed, 28 insertions(+), 26 deletions(-) diff --git a/all.md b/all.md index ba8c694..86f7bb7 100644 --- a/all.md +++ b/all.md @@ -1,12 +1,13 @@ ## All SIPS -| SIP # | Title | Status | -|---------------------------------------|-----------------------------|--------| -| [1](./sips/dkg.md) | DKG | open-for-discussion | -| [2](./sips/msg_struct_encoding.md) | Message struct and encoding | open-for-discussion | -| [3](./sips/qbft_sync.md) | QBFT Sync | open-for-discussion | -| [4](./sips/change_operator.md) | Change operators set | open-for-discussion | -| [5](./sips/ecies_share_encryption.md) | ECIES Share Encryption | open-for-discussion | -| [6](./sips/constant_qbft_timeout.md) | Constant QBFT timeout | open-for-discussion | -| [7](./sips/fork_support.md) | Fork Support | open-for-discussion | -| [8](./sips/pre_consensus_livness.md) | Pre-Consensus livness fix | open-for-discussion | \ No newline at end of file +| SIP # | Title | Status | +|-------------------------------------------------|---------------------------------------|---------------------| +| [1](./sips/dkg.md) | DKG | open-for-discussion | +| [2](./sips/msg_struct_encoding.md) | Message struct and encoding | open-for-discussion | +| [3](./sips/qbft_sync.md) | QBFT Sync | open-for-discussion | +| [4](./sips/change_operator.md) | Change operators set | open-for-discussion | +| [5](./sips/ecies_share_encryption.md) | ECIES Share Encryption | open-for-discussion | +| [6](./sips/constant_qbft_timeout.md) | Constant QBFT timeout | open-for-discussion | +| [7](./sips/fork_support.md) | Fork Support | open-for-discussion | +| [8](./sips/pre_consensus_livness.md) | Pre-Consensus livness fix | open-for-discussion | +| [9](./sips/re_registering_attack_protection.md) | Register Cluster copied shares attack | open-for-discussion | \ No newline at end of file diff --git a/core.md b/core.md index aec11df..878ea94 100644 --- a/core.md +++ b/core.md @@ -1,12 +1,13 @@ ## Core -| SIP # | Title | Status | -|------------------------------------|-----------------------------|--------| -| [1](./sips/dkg.md) | DKG | open-for-discussion | -| [2](./sips/msg_struct_encoding.md) | Message struct and encoding | open-for-discussion | -| [3](./sips/qbft_sync.md) | QBFT Sync | open-for-discussion | -| [4](./sips/change_operator.md) | Change operators set | open-for-discussion | -| [5](./sips/ecies_share_encryption.md) | ECIES Share Encryption | open-for-discussion | -| [6](./sips/constant_qbft_timeout.md) | Constant QBFT timeout | open-for-discussion | -| [7](./sips/fork_support.md) | Fork Support | open-for-discussion | -| [8](./sips/pre_consensus_livness.md) | Pre-Consensus livness fix | open-for-discussion | \ No newline at end of file +| SIP # | Title | Status | +|-------------------------------------------------|---------------------------------------|---------------------| +| [1](./sips/dkg.md) | DKG | open-for-discussion | +| [2](./sips/msg_struct_encoding.md) | Message struct and encoding | open-for-discussion | +| [3](./sips/qbft_sync.md) | QBFT Sync | open-for-discussion | +| [4](./sips/change_operator.md) | Change operators set | open-for-discussion | +| [5](./sips/ecies_share_encryption.md) | ECIES Share Encryption | open-for-discussion | +| [6](./sips/constant_qbft_timeout.md) | Constant QBFT timeout | open-for-discussion | +| [7](./sips/fork_support.md) | Fork Support | open-for-discussion | +| [8](./sips/pre_consensus_livness.md) | Pre-Consensus livness fix | open-for-discussion | +| [9](./sips/re_registering_attack_protection.md) | Register Cluster copied shares attack | open-for-discussion | \ No newline at end of file diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index 49fbf5b..e38442d 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -22,13 +22,13 @@ The attacker will pay fees for the validator to maintain the attack active. The honest user will need to exit the validator immediately. ## Rational & Design Goals -We need to protect users from having their validators being hijacked by malicious actors by ensuring that only the owner of the validator can register it to the SSV network. -This SIP proposes a solution using validator private key to sign on the address that making the registration and a nonce. -A nonce is required to prevent re-registering edge case where the removed validator address is compromised and the attacker can re-register it with the original address. -The BLS signature will be verified by the ssv nodes using the validator public key and making sure the nonce is higher than the last one. -The nonce will be on an account level and not a validator level to prevent the case where a validator is removed and re-registered by the same user. -It should be decided if it's needed to be stored on the contract or on the SSV nodes only. +This SIP proposes a method to safeguard users by preventing unauthorized access to their validators by harmful entities. The proposal ensures that only the legitimate owner of a validator can enroll it in the SSV network. The process involves using the validator's private key to sign the address that is registering, along with a nonce. +The nonce is a necessary addition to prevent a unique edge case where, if a validator address that has been removed is compromised, a malicious party could potentially re-register it using the original address. + +The BLS signature's authenticity will be confirmed by the SSV nodes, which will use the validator's public key and ensure that the nonce value is greater than the previous one. Instead of being on a validator level, the nonce will be on an account level to prevent scenarios where a validator is deregistered and re-registered by the same user. + +The decision regarding whether the nonce should be stored on the contract or solely on the SSV nodes still needs to be made. ## Specification The specification is divided into 3 parts: From a88471e0de32c41bc7807d1ce238a189e10ccdb3 Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Sun, 14 May 2023 11:58:31 +0300 Subject: [PATCH 03/13] formatting --- sips/re_registering_attack_protection.md | 34 +++++++++++++----------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index e38442d..b1cb8ca 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -4,22 +4,19 @@ ## Summary -A copied shares attack can happen by an attacker registering valid shares to a valid validator by frontrunning a valid register cluster transaction or re-registering a removed validator. +A "copied shares" attack can occur when a malicious actor registers valid shares to a legitimate validator by either "frontrunning" a valid registration of a cluster transaction, or re-registering a previously removed validator. -In both cases a validator will be running on SSV by a malicious user instead of the owner of the validator. +In both scenarios, a validator would be operating on the SSV network under the control of a harmful user instead of the rightful validator owner. #### Front-Running -A malicious attacker will front-run an honest user registering a validator. -The registration will pass as valid. -The attacker will pay fees for the validator to maintain the attack active. +In this scenario, a malicious actor could "front-run" a genuine user trying to register a validator. The registration would appear as legitimate. To keep the attack ongoing, the attacker would cover the validator's fees. -The honest user will need to exit the validator to make any change (remove/ change cluster). +To make any changes (such as removing or changing the cluster), the genuine user would need to exit the validator. #### Re-registering attack -An attacker will detect a removed validator (removed from the SSV network) and will re-register it immediately, preventing the owner from moving the validator away. -The attacker will pay fees for the validator to maintain the attack active. +In this case, an attacker could identify a validator that has been removed (from the SSV network) and quickly re-register it, thereby preventing the owner from transferring the validator elsewhere. Similar to the front-running scenario, the attacker would cover the validator's fees to keep the attack active. -The honest user will need to exit the validator immediately. +In response, the genuine user would need to exit the validator immediately. ## Rational & Design Goals This SIP proposes a method to safeguard users by preventing unauthorized access to their validators by harmful entities. The proposal ensures that only the legitimate owner of a validator can enroll it in the SSV network. The process involves using the validator's private key to sign the address that is registering, along with a nonce. @@ -31,16 +28,21 @@ The BLS signature's authenticity will be confirmed by the SSV nodes, which will The decision regarding whether the nonce should be stored on the contract or solely on the SSV nodes still needs to be made. ## Specification -The specification is divided into 3 parts: -1. Changing the validator registration process to include the validator's signature on the address. -2. Changing the validator map keys in the contract to include address in addition to the public key. -3. Adding the signature verification to the SSV nodes upon validator registration. +The specification is organized into three distinct sections: +1. Modifying the validator enrollment procedure to incorporate the validator's signature on the address. +2. Altering the validator map keys within the contract to include the address along with the public key. +3. Implementing signature verification within the SSV nodes during the validator registration process. + +> Please be aware: A new contract deployment will be necessary to modify the validator map. +> Furthermore, the uniqueness of a public key will be associated with each individual address, rather than being unique across the entire contract. ### SSV Keys -SSV keys should input should include the validator's address and the last account nonce. -It will use the validator private key to sign on the address and the incremented nonce. -The output should include the signature and the incremented nonce in addition to the current output. +Inputs for SSV keys should encompass both the validator's address and the most recent account nonce. + +These inputs will utilize the validator's private key to sign the address as well as the incremented nonce. + +The resultant output should not only contain the current output but also the signature and the incremented nonce. ### SSV Contract From bdc13e051aecb8610963a735af82cb466bd7f1ac Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Sun, 14 May 2023 12:00:30 +0300 Subject: [PATCH 04/13] formatting --- sips/re_registering_attack_protection.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index b1cb8ca..3b6208a 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -78,9 +78,11 @@ To: ) ``` -> Note: registerValidator function input parameters are not final and should consider gas fees optimisation. +> Note: The input parameters for the registerValidator function are not yet finalized and should be evaluated in light of optimizing gas fees. > -> 1. Combined shares, signature and nonce to one bytes array. -> 2. Combined signature and nonce to one bytes array. -> 3. Keep the all separate. +> Several potential arrangements are under consideration: +> 1. Consolidating shares, signature, and nonce into a single bytes array. +> 2. Merging signature and nonce into a single bytes array. +> 3. Keeping all elements separate. + From 1b362a386c38f0b0a65ce459eb60a27da380ad5a Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Mon, 15 May 2023 10:19:41 +0300 Subject: [PATCH 05/13] added ssv node section --- sips/re_registering_attack_protection.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index 3b6208a..4d7fc4f 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -72,7 +72,6 @@ To: uint64[] memory operatorIds, bytes calldata shares, bytes calldata signature, //signature on the address and nonce - uint256 nonce, uint256 amount, Cluster memory cluster ) @@ -85,4 +84,12 @@ To: > 2. Merging signature and nonce into a single bytes array. > 3. Keeping all elements separate. +### SSV Node +Every nonce associated with registration will be stored by the SSV node. + +The nonce will be kept in a mapping that links addresses to their respective nonces. + +The SSV node will confirm the signature of the address and nonce by using the validator's public key. + +The nonce should be sequentially larger than the previously stored nonce. \ No newline at end of file From 537498407c722e2d4a576ef80c60b914583c47e6 Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Mon, 15 May 2023 16:19:44 +0300 Subject: [PATCH 06/13] add contracts category --- contracts.md | 9 +++++---- sips/re_registering_attack_protection.md | 6 +++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/contracts.md b/contracts.md index 560956d..3ebc1c5 100644 --- a/contracts.md +++ b/contracts.md @@ -1,6 +1,7 @@ ## Core -| SIP # | Title | Status | -|-------------------------------|-----------------------------|--------| -| [4](./sips/change_operator.md) | Change operators set | open-for-discussion | -| [5](./sips/ecies_share_encryption.md) | ECIES Share Encryption | open-for-discussion | \ No newline at end of file +| SIP # | Title | Status | +|-------------------------------------------------|---------------------------------------|---------------------| +| [4](./sips/change_operator.md) | Change operators set | open-for-discussion | +| [5](./sips/ecies_share_encryption.md) | ECIES Share Encryption | open-for-discussion | +| [6](./sips/re_registering_attack_protection.md) | Register Cluster copied shares attack | open-for-discussion | \ No newline at end of file diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index 4d7fc4f..00d738c 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -1,6 +1,6 @@ -| Author | Title | Category | Status | -|-----------------------------| ------------------------------- | -------- | ------------------- | -| Lior Rutenberg (@lior-blox) | SSV Register Cluster copied shares attack | Core | open-for-discussion | +| Author | Title | Category | Status | +|-----------------------------| ------------------------------- |------------------| ------------------- | +| Lior Rutenberg (@lior-blox) | SSV Register Cluster copied shares attack | Core + Contracts | open-for-discussion | ## Summary From f532c230115c9fb7188d55412bd3c323e6b4dd20 Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Mon, 15 May 2023 16:27:26 +0300 Subject: [PATCH 07/13] clarify node level verification affect --- sips/re_registering_attack_protection.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index 00d738c..e38fbda 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -1,5 +1,5 @@ -| Author | Title | Category | Status | -|-----------------------------| ------------------------------- |------------------| ------------------- | +| Author | Title | Category | Status | +|-----------------------------|-------------------------------------------|------------------|---------------------| | Lior Rutenberg (@lior-blox) | SSV Register Cluster copied shares attack | Core + Contracts | open-for-discussion | ## Summary @@ -9,14 +9,14 @@ A "copied shares" attack can occur when a malicious actor registers valid shares In both scenarios, a validator would be operating on the SSV network under the control of a harmful user instead of the rightful validator owner. #### Front-Running -In this scenario, a malicious actor could "front-run" a genuine user trying to register a validator. The registration would appear as legitimate. To keep the attack ongoing, the attacker would cover the validator's fees. +In this scenario, a malicious actor could "front-run" an honest user trying to register a validator. The registration would appear as legitimate. To keep the attack ongoing, the attacker would cover the validator's fees. -To make any changes (such as removing or changing the cluster), the genuine user would need to exit the validator. +To make any changes (such as removing or changing the cluster), the honest user would need to exit the validator. #### Re-registering attack In this case, an attacker could identify a validator that has been removed (from the SSV network) and quickly re-register it, thereby preventing the owner from transferring the validator elsewhere. Similar to the front-running scenario, the attacker would cover the validator's fees to keep the attack active. -In response, the genuine user would need to exit the validator immediately. +In response, the honest user would need to exit the validator immediately. ## Rational & Design Goals This SIP proposes a method to safeguard users by preventing unauthorized access to their validators by harmful entities. The proposal ensures that only the legitimate owner of a validator can enroll it in the SSV network. The process involves using the validator's private key to sign the address that is registering, along with a nonce. @@ -25,7 +25,8 @@ The nonce is a necessary addition to prevent a unique edge case where, if a vali The BLS signature's authenticity will be confirmed by the SSV nodes, which will use the validator's public key and ensure that the nonce value is greater than the previous one. Instead of being on a validator level, the nonce will be on an account level to prevent scenarios where a validator is deregistered and re-registered by the same user. -The decision regarding whether the nonce should be stored on the contract or solely on the SSV nodes still needs to be made. +> Note: While a validator's registration may be accepted at the contract level, it could be invalidated at the node level if the BLS signature verification fails - a process the contract cannot perform. Consequently, despite its accepted registration, the validator will not be able to execute its assigned duties due to this node-level validation failure. + ## Specification The specification is organized into three distinct sections: From 95ad0aebd168a2c023568b1a430fc93314d8fdb5 Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Tue, 16 May 2023 17:54:32 +0300 Subject: [PATCH 08/13] add remove validtor case --- sips/re_registering_attack_protection.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index e38fbda..c0f52f3 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -49,6 +49,8 @@ The resultant output should not only contain the current output but also the sig Changing the validator mapping to include the address in addition to the public key. +Including operators in the validator structure allows for the validation of a validator's affiliation with the cluster when it's being removed. + From: ```solidity struct Validator { @@ -78,12 +80,6 @@ To: ) ``` -> Note: The input parameters for the registerValidator function are not yet finalized and should be evaluated in light of optimizing gas fees. -> -> Several potential arrangements are under consideration: -> 1. Consolidating shares, signature, and nonce into a single bytes array. -> 2. Merging signature and nonce into a single bytes array. -> 3. Keeping all elements separate. ### SSV Node From 82be1a63bf33002fb9b5852471ce1fbb1128e477 Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Tue, 16 May 2023 18:00:30 +0300 Subject: [PATCH 09/13] remove ssv keys ref --- sips/re_registering_attack_protection.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index c0f52f3..ad884d6 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -38,13 +38,6 @@ The specification is organized into three distinct sections: > Please be aware: A new contract deployment will be necessary to modify the validator map. > Furthermore, the uniqueness of a public key will be associated with each individual address, rather than being unique across the entire contract. -### SSV Keys -Inputs for SSV keys should encompass both the validator's address and the most recent account nonce. - -These inputs will utilize the validator's private key to sign the address as well as the incremented nonce. - -The resultant output should not only contain the current output but also the signature and the incremented nonce. - ### SSV Contract Changing the validator mapping to include the address in addition to the public key. From d2ca9310c3c5a2189040d3642f8c7ecf7d412c6d Mon Sep 17 00:00:00 2001 From: Lior Rutenberg Date: Tue, 16 May 2023 18:03:51 +0300 Subject: [PATCH 10/13] removed note regarding contract not upgradable --- sips/re_registering_attack_protection.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index ad884d6..662f64d 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -35,8 +35,6 @@ The specification is organized into three distinct sections: 2. Altering the validator map keys within the contract to include the address along with the public key. 3. Implementing signature verification within the SSV nodes during the validator registration process. -> Please be aware: A new contract deployment will be necessary to modify the validator map. -> Furthermore, the uniqueness of a public key will be associated with each individual address, rather than being unique across the entire contract. ### SSV Contract From 8aad9ac1b91f7ac861db120be0c3d03fab76b1c7 Mon Sep 17 00:00:00 2001 From: Gal Rogozinski Date: Thu, 14 Dec 2023 11:25:56 +0200 Subject: [PATCH 11/13] Registration Replay fix --- sips/re_registering_attack_protection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index 662f64d..9a4980d 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -13,7 +13,7 @@ In this scenario, a malicious actor could "front-run" an honest user trying to r To make any changes (such as removing or changing the cluster), the honest user would need to exit the validator. -#### Re-registering attack +#### Registration replay attack In this case, an attacker could identify a validator that has been removed (from the SSV network) and quickly re-register it, thereby preventing the owner from transferring the validator elsewhere. Similar to the front-running scenario, the attacker would cover the validator's fees to keep the attack active. In response, the honest user would need to exit the validator immediately. From 1883af0ceeb334a96e228f1f70299c83b5a38c34 Mon Sep 17 00:00:00 2001 From: Gal Rogozinski Date: Thu, 14 Dec 2023 11:28:45 +0200 Subject: [PATCH 12/13] approved --- sips/re_registering_attack_protection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index 9a4980d..df87f8e 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -1,6 +1,6 @@ | Author | Title | Category | Status | |-----------------------------|-------------------------------------------|------------------|---------------------| -| Lior Rutenberg (@lior-blox) | SSV Register Cluster copied shares attack | Core + Contracts | open-for-discussion | +| Lior Rutenberg (@lior-blox) | SSV Register Cluster copied shares attack | Core + Contracts | approved | ## Summary From a42dccbc33b527b6d408356bf690b76fe7dd4139 Mon Sep 17 00:00:00 2001 From: Marco Tabasco Date: Wed, 20 Dec 2023 15:32:22 +0100 Subject: [PATCH 13/13] update solidity code example --- sips/re_registering_attack_protection.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/sips/re_registering_attack_protection.md b/sips/re_registering_attack_protection.md index df87f8e..7325a75 100644 --- a/sips/re_registering_attack_protection.md +++ b/sips/re_registering_attack_protection.md @@ -38,9 +38,10 @@ The specification is organized into three distinct sections: ### SSV Contract -Changing the validator mapping to include the address in addition to the public key. +Changing the validator mapping to include the caller address in addition to the public key. -Including operators in the validator structure allows for the validation of a validator's affiliation with the cluster when it's being removed. +Including operators in the validator hashed value allows for the validation of a validator's affiliation with the cluster when it's being removed. +The last bit of the hashed value is used to indicate whether the validator is active or inactive. From: ```solidity @@ -52,15 +53,10 @@ From: ``` To: ```solidity - struct Validator { - bytes32 hashedOperators; - bool active; - } - mapping(bytes32 => Validator) public validatorPKs; + // Maps each validator's public key to its hashed representation of: operator Ids used by the validator and active / inactive flag (uses LSB) + mapping(bytes32 => bytes32) validatorPKs; //example of setting the mapping - validatorPKs[keccak256(abi.encodePacked(publicKey, msg.sender))] = Validator({hashedOperators: keccak256(operatorIds), active: true}); - function registerValidator( bytes calldata publicKey, uint64[] memory operatorIds, @@ -68,8 +64,12 @@ To: bytes calldata signature, //signature on the address and nonce uint256 amount, Cluster memory cluster - ) - + ) { + ... + bytes32 hashedPk = keccak256(abi.encodePacked(publicKey, msg.sender)); + validatorPKs[hashedPk] = bytes32(uint256(keccak256(abi.encodePacked(operatorIds))) | uint256(0x01)); // set LSB to 1 + ... + } ``` ### SSV Node