faq: add threat model from gdoc #211
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for obol-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
6 tasks
OisinKyne
approved these changes
Aug 2, 2023
docs/int/faq/threat_model.md
Outdated
|
|
||
| While to the Beacon Chain, a distributed validator is seen in much the same way as a regular validator, and thus retains some of the same security considerations, Charon’s threat model is different from a validator client’s threat model because of its general design. | ||
|
|
||
| While a validator client owns and operates on a set of validator private keys, the design of Charon allows its node operators to rarely if ever see the complete set of validator private key shares, relying on modern cryptography to split them into smaller chunks. |
There was a problem hiding this comment.
Suggested change
| While a validator client owns and operates on a set of validator private keys, the design of Charon allows its node operators to rarely if ever see the complete set of validator private key shares, relying on modern cryptography to split them into smaller chunks. | |
| While a validator client owns and operates on a set of validator private keys, the design of Charon allows its node operators to rarely (if ever) see the complete validator private keys, relying instead on modern cryptography to generate partial private key shares. |
docs/int/faq/threat_model.md
Outdated
|
|
||
| While a validator client owns and operates on a set of validator private keys, the design of Charon allows its node operators to rarely if ever see the complete set of validator private key shares, relying on modern cryptography to split them into smaller chunks. | ||
|
|
||
| An Ethereum distributed validator employs advanced signature primitives so that no operator ever handles the full validator key in any standard lifecycle step: the BLS digital signature scheme employed by the Ethereum network allows distributed validators to individually sign a blob of data and then aggregate the resulting signatures in a transparent manner, never requiring any of the participating parties to know the full secret in advance. |
There was a problem hiding this comment.
Suggested change
| An Ethereum distributed validator employs advanced signature primitives so that no operator ever handles the full validator key in any standard lifecycle step: the BLS digital signature scheme employed by the Ethereum network allows distributed validators to individually sign a blob of data and then aggregate the resulting signatures in a transparent manner, never requiring any of the participating parties to know the full secret in advance. | |
| An Ethereum distributed validator employs advanced signature primitives such that no operator ever handles the full validator private key in any standard lifecycle step: the [BLS digital signature scheme](https://en.wikipedia.org/wiki/BLS_digital_signature) employed by the Ethereum network allows distributed validators to individually sign a blob of data and then aggregate the resulting signatures in a transparent manner, never requiring any of the participating parties to know the full private key to do so. |
docs/int/faq/threat_model.md
Outdated
| To do so, the cluster must have knowledge of the Ethereum validator’s private key. | ||
|
|
||
| The design and implementation of Charon minimizes the chances of this by splitting the Ethereum validator private keys into parts, which are then assigned to each node operator. | ||
| A distributed key generation (DKG) process is used in order to evenly and safely create the private key shares without any central party having access to the full private key. |
There was a problem hiding this comment.
Suggested change
| A distributed key generation (DKG) process is used in order to evenly and safely create the private key shares without any central party having access to the full private key. | |
| A [distributed key generation](https://en.wikipedia.org/wiki/Distributed_key_generation) (DKG) process is used in order to evenly and safely create the private key shares without any central party having access to the full private key. |
docs/int/faq/threat_model.md
Outdated
| The design and implementation of Charon minimizes the chances of this by splitting the Ethereum validator private keys into parts, which are then assigned to each node operator. | ||
| A distributed key generation (DKG) process is used in order to evenly and safely create the private key shares without any central party having access to the full private key. | ||
|
|
||
| The cryptography primitives employed in Charon allow a subset of the node operator’s key shares to reconstruct the original private key, hence signing data. |
There was a problem hiding this comment.
Suggested change
| The cryptography primitives employed in Charon allow a subset of the node operator’s key shares to reconstruct the original private key, hence signing data. | |
| The cryptography primitives employed in Charon can allow a threshold of the node operator’s private key shares to be reconstructed into the whole validator private key if needed. |
docs/int/faq/threat_model.md
Outdated
Comment on lines
58
to
60
| A distributed validator cluster can be started in two ways: | ||
| An existing Ethereum validator private key is split by the private key holder, and distributed in a trusted manner among the operators. | ||
| The operators participate in a distributed key generation (DKG) process, to create private key shares that collectively can be used to sign validation duties as an Ethereum distributed validator. The full private key for the cluster never exists in one place during or after the DKG. |
There was a problem hiding this comment.
Suggested change
| A distributed validator cluster can be started in two ways: | |
| An existing Ethereum validator private key is split by the private key holder, and distributed in a trusted manner among the operators. | |
| The operators participate in a distributed key generation (DKG) process, to create private key shares that collectively can be used to sign validation duties as an Ethereum distributed validator. The full private key for the cluster never exists in one place during or after the DKG. | |
| A distributed validator cluster can be started in two ways: | |
| 1. An existing Ethereum validator private key is split by the private key holder, and distributed in a trusted manner among the operators. | |
| 2. The operators participate in a distributed key generation (DKG) process, to create private key shares that collectively can be used to sign validation duties as an Ethereum distributed validator. The full private key for the cluster never exists in one place during or after the DKG. |
docs/int/faq/threat_model.md
Outdated
Comment on lines
89
to
90
| No knowledge of the topology of the cluster: The attacker doesn’t know where each cluster node is located and so can’t force fault tolerance +1 nodes offline if it can’t find them. | ||
| Knowledge of the topology of the network (or part of it) is possessed: the OA can operate DDoS attacks or try breaking into node’s servers - at that point, the “rogue node operator” scenario applies. |
There was a problem hiding this comment.
Suggested change
| No knowledge of the topology of the cluster: The attacker doesn’t know where each cluster node is located and so can’t force fault tolerance +1 nodes offline if it can’t find them. | |
| Knowledge of the topology of the network (or part of it) is possessed: the OA can operate DDoS attacks or try breaking into node’s servers - at that point, the “rogue node operator” scenario applies. | |
| 1. No knowledge of the topology of the cluster: The attacker doesn’t know where each cluster node is located and so can’t force fault tolerance +1 nodes offline if it can’t find them. | |
| 2. Knowledge of the topology of the network (or part of it) is possessed: the OA can operate DDoS attacks or try breaking into node’s servers - at that point, the “rogue node operator” scenario applies. |
docs/int/faq/threat_model.md
Outdated
Comment on lines
121
to
122
| A lock file used to address operator’s nodes, define the Ethereum validator public keys and the public key shares associated with it | ||
| A cluster definition file used to define the operator’s addresses and identities during the DKG process |
There was a problem hiding this comment.
Suggested change
| A lock file used to address operator’s nodes, define the Ethereum validator public keys and the public key shares associated with it | |
| A cluster definition file used to define the operator’s addresses and identities during the DKG process | |
| - A lock file used to address operator’s nodes, define the Ethereum validator public keys and the public key shares associated with it | |
| - A cluster definition file used to define the operator’s addresses and identities during the DKG process |
docs/int/faq/threat_model.md
Outdated
|
|
||
| By doing that, the OA can edit the lock file as it sees fit, leading to the “rogue node operator” scenario. An OA or RNO might also manage to social engineer their way into convincing other operators into running their malicious lock file with verification disabled. | ||
|
|
||
| The likelihood of this scenario is low: an OA would need to compromise every node operator through social engineering to both use a different set of files, and to run its cluster with --no-verify. |
There was a problem hiding this comment.
Suggested change
| The likelihood of this scenario is low: an OA would need to compromise every node operator through social engineering to both use a different set of files, and to run its cluster with --no-verify. | |
| The likelihood of this scenario is low: an OA would need to compromise every node operator through social engineering to both use a different set of files, and to run its cluster with `--no-verify`. |
docs/int/faq/threat_model.md
Outdated
|
|
||
| The lock file is signed and validated by all the nodes participating in the cluster: assuming good security practices on the node operator side, and no bugs in Charon or its dependencies’ implementations, this scenario is unlikely. | ||
|
|
||
| If one or more node operators are using less than ideal security practices an OA could rewire the Charon CLI flags to include the --no-verify flags, which disables lock file signature and hash verification (usually intended only for development purposes). |
There was a problem hiding this comment.
Suggested change
| If one or more node operators are using less than ideal security practices an OA could rewire the Charon CLI flags to include the --no-verify flags, which disables lock file signature and hash verification (usually intended only for development purposes). | |
| If one or more node operators are using less than ideal security practices an OA could rewire the Charon CLI flags to include the `--no-verify` flags, which disables lock file signature and hash verification (usually intended only for development purposes). |
docs/int/faq/threat_model.md
Outdated
|
|
||
| As with any computing system, security considerations are to be expected in order to keep the environment safe. | ||
|
|
||
| From the point of view of an Ethereum validator entity running their services through a DVT provider helps greatly with availability, minimizing slashing risks and maximizing participation to the network. |
There was a problem hiding this comment.
Suggested change
| From the point of view of an Ethereum validator entity running their services through a DVT provider helps greatly with availability, minimizing slashing risks and maximizing participation to the network. | |
| From the point of view of an Ethereum validator entity running their services through a DVT provider helps greatly with availability, minimizing slashing risks, and maximizing participation to the network. |
I prefer oxford commas :) https://en.wikipedia.org/wiki/Serial_comma
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Adds content of this document under FAQ.
ticket: #217