mirror of https://github.com/poanetwork/quorum.git
Chaddy H
Samer Falah
parent
53105b1640
commit
90bbfb18c8
|
|
@ -106,4 +106,4 @@ Your node is now operational and you may attach to it with `geth attach new-node
|
|||
|
||||
|
||||
## Enabling permissioned configuration
|
||||
Quorum ships with a permissions system based on a custom whitelist. Detailed documentation is available in [Network Permissioning](../../Security/Security%20%26%20Permissioning).
|
||||
Quorum ships with a permissions system based on a custom whitelist. Detailed documentation is available in [Network Permissioning](../../Security/Framework/Quorum%20Network%20Security/Nodes/Permissioning/Network%20Permissioning).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
## Frontend
|
||||
|
||||
As any traditional application, dApps Client/Server component has to follow application security best practices.
|
||||
Its recommended to use a Secure Software Development Lifecycle (SSDLC) to implement any application.
|
||||
In general Secure Development Lifecycle include the following phases :
|
||||
|
||||
- Risk Assessment Phase.
|
||||
- Threat Modeling, and Secure Design Review Phase.
|
||||
- Static Source Code Analysis Phase.
|
||||
- Security Testing, and Manual Secure Source Review Phase.
|
||||
- Security Assessment of Configuration of Deployment Pipeline Phase.
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
**Smart Contracts Security** must be considered as any other application security, it might contain logical vulnerabilities, insecure design and it might run on vulnerable components (ledgers). However Smart Contracts
|
||||
are the core element of Ethereum Blockchain, unlike other software concepts it is constrained by several Blockchain Technology primitives:
|
||||
|
||||
- Smart Contracts runtime is sandboxed, this means obtaining a secure randomness source is hard.
|
||||
- Smart Contracts can hold, transfer or destroy funds making them an economical risk component.
|
||||
- Smart Contracts cannot be directly upgraded unless an upgrade mechanism is introduced from the design phase.
|
||||
- Smart Contracts are immutable, and have an irrevocable self destruction feature.
|
||||
- Smart Contracts can have one or multiple owners.
|
||||
|
||||
### Ownership
|
||||
Unlike traditional software management process Smart Contracts support the following technologically enforced ownership model:
|
||||
|
||||
Single Ownership:
|
||||
The contract has one owner who is responsible for the contract administration process.
|
||||
|
||||
Shared Custody Ownership:
|
||||
Suitable for agreement between two or more parties in a network of N parties, where any party can unilaterally perform administrative action over the contract.
|
||||
|
||||
Consortium Based Ownership:
|
||||
Is a form of expanded Shared Custody Ownership that requires consensus over the administrative actions.
|
||||
|
||||
|
||||
### Security Patterns:
|
||||
|
||||
**Checks-Effects-Interaction Pattern** Interacting with other contracts should always be the last step in contract function. It’s crucial that the current contract has finished its functionality before handling control to other contract and does not depend on the execution of the other contract.
|
||||
|
||||
**Circuit Breaker** is logical emergency stop execution logic. Implementing emergency stops in logic of smart contract is a good security practice. A Circuit breaker can be triggered manually by trusted parties included in the contract like the contract owner or by using programmatic consensus rules that automatically trigger the circuit breaker when the defined conditions are met.
|
||||
|
||||
**Rate Limit** smart contract function within a period of time allows better control of resources that can be abused.
|
||||
|
||||
**Speed Bumps** introduces a delay in the action execution allowing a time to act if action is considered malicious.
|
||||
|
||||
|
||||
### Common Contract Vulnerabilities
|
||||
|
||||
**Reentrancy**: Reentrancy occurs when external contract calls are allowed to make new calls to the calling contract before the initial execution is complete. For a function, this means that the contract state may change in the middle of its execution as a result of a call to an untrusted contract or the use of a low level function with an external address.
|
||||
|
||||
**Access Control**: While insecure visibility settings give attackers straightforward ways to access a contract's private values or logic, access control bypasses are sometimes more subtle. These vulnerabilities can occur when contracts use the deprecated tx.origin to validate callers, handle large authorization logic with lengthy require and make reckless use of delegatecall in proxy libraries or proxy contracts.
|
||||
|
||||
**Arithmetic**: Integer overflows and underflows are not a new class of vulnerability, but they are especially dangerous in smart contracts, where unsigned integers are prevalent and most developers are used to simple int types (which are often just signed integers). If overflows occur, many benign-seeming codepaths become vectors for theft or denial of service.
|
||||
|
||||
**Unchecked Low Level Calls**: One of the deeper features of Solidity are the low level functions such as call(), callcode(), delegatecall() and send(). Their behavior in accounting for errors is quite different from other Solidity functions, as they will not propagate (or bubble up) and will not lead to a total reversion of the current execution. Instead, they will return a boolean value set to false, and the code will continue to run. This could surprise developers and, if the return value of such low-level calls are not checked, it could lead to fail-opens and other unwanted outcomes
|
||||
|
||||
**Bad Randomness**: Is hard to get right in Ethereum. While Solidity offers functions and variables that can access apparently hard-to-predict values, they are generally either more public than they seem. Because randomness sources are to an extent predictable in ethereum, malicious users can generally replicate it and attack the function relying on its unpredictablility and this applies to dApps built on top of Quorum too.
|
||||
|
||||
**Front Running**: In public ethereum client miners always get rewarded via gas fees for running code on behalf of externally owned addresses (EOA), users can specify higher fees to have their transactions mined more quickly. Since the Ethereum blockchain is public, everyone can see the contents of others' pending transactions. This means if a given user is revealing the solution to a puzzle or other valuable secret, a malicious user can steal the solution and copy their transaction with higher fees to preempt the original solution. If developers of smart contracts are not careful, this situation can lead to practical and devastating front-running attacks. On the other hand since Quorum does not uses Proof Of Work (PoW) in its consensus algorithm and the gas cost is zero, PoW mining related vulnerabilities are not applicable when building on top of Quorum, however fron-running remains a risk and will dependent on the consensus algorithm in use.
|
||||
|
||||
**Time Manipulation**: From locking a token sale to unlocking funds at a specific time, contracts sometimes need to rely on the current time. This is usually done via block.timestamp or its alias now in Solidity. In public ethereum this value comes from the miners, however in Quorum it comes from the minter, or validators, as result smart contracts should avoid relying strongly on the block time for critical decision making. Note that block.timestamp should not be used for the generation of random numbers.
|
||||
|
||||
**Short Addresses**: attacks are a side-effect of the EVM itself accepting incorrectly padded arguments. Attackers can exploit this by using specially-crafted addresses to make poorly coded clients encode arguments incorrectly before including them in transactions.
|
||||
|
||||
|
||||
### Security Checklist
|
||||
|
||||
#### Ownership
|
||||
|
||||
!!! success "No ownership contacts must be prevented in Enteprise Blockchain."
|
||||
|
||||
!!! success "Contracts must include initilization phase where all owners are clearly identified and set `init(owners_list)`."
|
||||
|
||||
!!! success "Identify contract ownership model before starting the design of the smart contract logic."
|
||||
|
||||
!!! success "Define the consensus model for Constortium Based Ownership."
|
||||
|
||||
!!! success "Contract upgradability and ownership functionalies must verify new addresses are valid."
|
||||
|
||||
!!! success "Ownership relate events must be broadcasted to all the network participants."
|
||||
|
||||
!!! success "In a Constortium based ownership structure changing activities that are bound to approval from Constortium members before they are commited (E.g editing Constortium structure) must have an aproval pending expiration date."
|
||||
|
||||
!!! success "Constorium based voting must involve realtime notification through EVM event emition. "
|
||||
|
||||
#### Contract Implementation
|
||||
|
||||
!!! success "Contract should use a locked compiler version"
|
||||
|
||||
!!! success "The compiler version should be consistent across all contracts"
|
||||
|
||||
!!! success "Contract should not shadow or overwrite built-in functions"
|
||||
|
||||
!!! success "Contract should never use tx.origin as authorization mechanism "
|
||||
|
||||
!!! success "Contract should never use timestamp as source of randomness"
|
||||
|
||||
!!! success "Contract should never use block number or hash as a source for randomness"
|
||||
|
||||
!!! success "Contract should never use block number or timestamp as critical decision making conditions"
|
||||
|
||||
!!! success "Contract should never misuse multiple inheritance "
|
||||
|
||||
!!! success "Modifiers must perserve the contract state or performing an external call"
|
||||
|
||||
!!! success "Contract should never contain cross function race conditions"
|
||||
|
||||
!!! success "Contract should never use plain arithmetic computation instead safe math should be used"
|
||||
|
||||
!!! success "Contract fallback functions should be free of unknown states that might introduce security implications"
|
||||
|
||||
!!! success "Contract should avoid shadowed variables "
|
||||
|
||||
!!! success "Contract public variables/functions should be reviewed to ensure visibility is appropriate"
|
||||
|
||||
!!! success "Contract private variables should not contain sensitive data "
|
||||
|
||||
!!! success "Contract functions should explicitly declare visibility"
|
||||
|
||||
!!! success "Contract shared code must be marked as private or internal"
|
||||
|
||||
!!! success "Contract public functions should perform proper authorization checks "
|
||||
|
||||
!!! success "Contract should validate the input of all public and external functions"
|
||||
|
||||
!!! success "Contract using old solidity version constructor name must match contract name"
|
||||
|
||||
!!! success "Contract should explicitly mark untrusted contracts as 'untrusted'"
|
||||
|
||||
!!! success "Contract functions logic should perform state changing actions before making external calls"
|
||||
|
||||
!!! success "Contract logic should use send() and transfer() over call.value when possible"
|
||||
|
||||
!!! success "Contract usage of delegatecall should be properly handled"
|
||||
|
||||
!!! success "Contract logic must correctly handle return value of any external call"
|
||||
|
||||
!!! success "Contract must never assume it has been created with balance of 0 "
|
||||
|
||||
!!! success "Contract logic should not contain loops that are vulnerable to denial of service attacks"
|
||||
|
||||
!!! success "Multiparty contract logic action should not be dependent on a single party"
|
||||
|
||||
!!! success "Prevent Toke transfers to 0x0 address"
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
## Objectives
|
||||
The **objective** of this framework is to provide an in-depth reference to Quorum and
|
||||
Decentralized Applications (dApps) security best practices.
|
||||
|
||||
The following outlines the *scope* of the framework:
|
||||
|
||||
- Quorum architecture security
|
||||
- Quorum network security guidelines
|
||||
- Decentralized application (dApps) security best practices
|
||||
|
||||
|
||||
## References
|
||||
+ https://github.com/ethereum/go-ethereum/wiki
|
||||
+ https://github.com/jpmorganchase/quorum/wiki
|
||||
+ https://www.dasp.co/
|
||||
+ https://entethalliance.org/technical-documents/
|
||||
+ https://solidity.readthedocs.io/en/v0.5.7/#
|
||||
+ https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
|
||||
+ https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=925957
|
||||
+ https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE1TH5G
|
||||
+ https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
|
||||
+ https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
When creating a Consortium the following elements should be taken in consideration:
|
||||
|
||||
### Governance
|
||||
Chosen structure must not only be appropriate to permit efficient and effective operations of the Consortium,
|
||||
but also fulfill the concerns of those that form part of it equally.
|
||||
|
||||
### Ownership
|
||||
The nature of blockchain technology also increases the risk of accidental data exposure. In order to manage this risk
|
||||
ownership of Intellectual Properties (IP), and assets should be documented, and agreed upon.
|
||||
|
||||
### Liability
|
||||
Most network operational activities are benign, but this is not true in all cases,
|
||||
and even in otherwise low-risk Consortium, where the membership constitutes “market power” under the antitrust
|
||||
laws, a significant percentage of the competitors in a given product or service space might be members. The potential
|
||||
for inadvertent mistakes, as well as the level of potential scrutiny by government regulators, is higher.
|
||||
In such a situation, individual members may wish to maintain tighter control over what can – and more importantly, what cannot – be done
|
||||
by the organization, and its members without proper prior consensus in order to reduce the risk and liability.
|
||||
|
||||
### Activities
|
||||
Interconnecting multiple independent networks comes with risk factors. In order to
|
||||
build a controls to minimize a risk, the activities that are expected to be performed in the network must be documented.
|
||||
|
||||
### Security Checklist
|
||||
|
||||
!!! success "Use Byznatine fault tolerant consensus protocol in case nodes are managed by un-trusted participants"
|
||||
|
||||
!!! success "Consortium member should provide a reasonable network Service-Level Agreement (SLA)."
|
||||
|
||||
!!! success "Ensure Private/Public payloads data is stored in a appropiate Geografical legislation area. "
|
||||
|
||||
!!! success "Document the Consortium Governance Structure, Ownership, Liability, Memberships, Activities. "
|
||||
|
||||
!!! success "Document the Organizational, and technological requirements to join the Consortium. "
|
||||
|
||||
!!! success "Ensure Consortium members be known to every participant in the network."
|
||||
|
||||
!!! success "Ensure Private/Public paylaod data is compliant with privacy policies. "
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
**Quorum client** is a thick-client whose Private Transaction feature operation depends on a Transaction Manager Client that encrypts and decrypts
|
||||
private transactions payload. Both Quorum client and its dependencies i.e, Transaction Manager, Peers, and Enclave use traditional TCP/UDP transport layer to communicate.
|
||||
|
||||
As any asset in a network its security depends on multiple elements (E.g the security of the Host, Data, and Accounts). In Quorum it will be the security of
|
||||
the Client and Transaction Manager host/host-runtime, encryption keys, Consensus runtime and Network Access Controls.
|
||||
|
||||
### Host Security
|
||||
Any asset in a Quorum network (Client Host, Transaction Manager Host, Private Transaction Storage Host, ..etc ) must be hardened following industry best practices. A host IDS should be used to detect any malicious activities on the host. Direct access to the host should not be allowed, instead a jump server should be used and access limited to small number of administrators.
|
||||
Operating systems, software and services will have vulnerabilities. Quorum network hosts must implement a robust patch management program.
|
||||
|
||||
### Client Security
|
||||
Quorum client instance exposes a JSON-Remote Procedure Call (RPC) interface through HTTP, Web Socket, or Inter-Process communication techniques. The JSON-RPC interfaces
|
||||
allows the remote interaction with the ledger features, and Smart Contracts. The JRPC interface must be secured in order to preserve the integrity of the ledger runtime.
|
||||
|
||||
Each client in the network must be uniquely identified. In Quorum this is done by using nodes identity. Node identity is represented through a public key/private key, where
|
||||
the public key identifies the node in the network. Quorum Smart Contract Permissioning models depends on nodes identity to authorize TCP level communication between nodes, as such securing
|
||||
the private key of a node is a paramount activity required to prevent unauthorized node from joining the network.
|
||||
|
||||
|
||||
### Users Security
|
||||
Blockchain technology uses public key cryptography to protect the integrity of transactions and blocks. The security of a user’s Private keys is dependent on the security operation elements implemented to
|
||||
preserve the Private key from compromise. In Ethereum Accounts Private keys are encrypted with user specified seed (password). Users password should never be saved across the ecosystem or stored in ledger host in any form.
|
||||
|
||||
### Security Checklist
|
||||
|
||||
#### Host
|
||||
|
||||
!!! success "Harden Quorum Host Operating System (e.g remove irrelevant services, root access...etc)."
|
||||
|
||||
!!! success "Disable direct remote network access to Quorum host management interface in production."
|
||||
|
||||
!!! success "Use Host Based Intrusion Detection System (HIDS) to monitoring Quorum node host."
|
||||
|
||||
!!! success "Enable Host Based Firewall Rules that enforces network access to JRPC interface to only a preidentified, trusted and required systems."
|
||||
|
||||
!!! success "Implement a robust Patch Management Program, and always keep the host updated to latest stable version."
|
||||
|
||||
!!! success "Ensure host level Isolation of responsability between Quorum client and its dependency (e.g do not run the transaction manager and its database in the same host) "
|
||||
|
||||
!!! success "Ensure Quorum network hosts run with appropiate service level agreement (SLA) that can ensure a defense against non-vulnerability based denial of service."
|
||||
|
||||
#### Client
|
||||
|
||||
!!! success "Enable Secure Transport Security (TLS) to encrypt all communications from/to JRPC interface to prevent data leakage and man in the middle attacks (MITM)."
|
||||
|
||||
!!! success "Enable Quorum Enterprise JRPC authorization model to enforce atomic access controls to ledger modules functionalities (e.g personal.OpenWallet)."
|
||||
|
||||
!!! success "Implement a robust Patch Management Prgoram, and always keep the client updated to latest stable version."
|
||||
|
||||
!!! success "Ensure Quorum client run configuration is not started with unlocked accounts options."
|
||||
|
||||
!!! success "Ensure cross domain access of the JRPC interface is configured appropriately. "
|
||||
|
||||
!!! success "Ensure peer discovery is appropriately set based on the consortium requirements."
|
||||
|
||||
!!! success "In Raft Based Consensus there is no guarantee a leader would not be acting maliciously, hence raft should not be used in environment where network ledger is managed by third party authorities."
|
||||
|
||||
!!! success "Quorum clients must run with metrics collection capability in order to preserve operational security."
|
||||
|
||||
#### Users
|
||||
|
||||
!!! success "Accounts Private Key encryption password should never be stored in the ledger host in any form."
|
||||
|
||||
!!! success "In an architecture where accounts private keys are not offloaded to ledger node clients, the encrypted private keys should be backed-up to secure environment regularly. "
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
### Monitoring
|
||||
Monitoring a network for security events start from log collection activity. Quorum network as any other network should produce logs, that must be analyzed for anomalies.
|
||||
The following parameters are of interest to be collected and analyzed:
|
||||
|
||||
- Hosts access and events
|
||||
- Ethereum accounts on the network
|
||||
- Active ledger, transaction manager nodes in the network
|
||||
- Public and Private transaction rates per account in the network.
|
||||
- Number of public Smart contracts in the network.
|
||||
- Network connections to ledger nodes and metadata.
|
||||
- Consensus protocol metadata (E.g Block creation rate, and source ...etc)
|
||||
|
||||
### Security Checklist
|
||||
|
||||
!!! success "Ensure all activities of Quorum hosts are being logged to centralized log system"
|
||||
|
||||
!!! success "Centralized log system most be able to provide query capabilites over the following parameters:"
|
||||
- Ethereum accounts on the network
|
||||
- Active ledger, transaction manager nodes in the network
|
||||
- Public and Private transaction rates per account in the network.
|
||||
- Number of public Smart contracts in the network.
|
||||
- Network connections to ledger nodes and metadata.
|
||||
- Consensus protocol metadata (E.g Block creation rate, and source ...etc)
|
||||
|
||||
!!! success "Logs must be backed-up and integrity verified. "
|
||||
|
||||
!!! success "An alerting system should be put in place in order to monitor consensus protocol anomalies "
|
||||
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
### Tessera
|
||||
[Tessera](https://github.com/jpmorganchase/tessera/wiki) is Quorum's Transaction Manager. Quorum privacy features depends on Tessera to Encrypt/Decrypt, and broadcast the orchestrations of a private transaction payload.
|
||||
Tessera uses an enclave to perform the encryption/decryption of private transactions payload. The encryption keys should be stored in high secure environments such a hardware security module (HSM).
|
||||
Tessera communication with its dependencies (Enclave, Quorum node, Payload Storage Database, Secret Storage Service) must be secured. To ensure the privacy and authentication of the communication between Tessera the network must be configured to Certificate Based Mutual Authentication (MTLS).
|
||||
|
||||
### Encryption Keys
|
||||
Encryption keys is the most critical element of the privacy model, if the encryption key is compromised the network loses its privacy. Tessera support integration with Trusted Platform Modules (TPM) and Hardware Security Modules (HSM) to reduce surface attack and provide highly secure environment.
|
||||
|
||||
|
||||
### Security Checklist
|
||||
|
||||
!!! success "Tessera should run in independent network segment in production"
|
||||
|
||||
!!! success "Tessera must leverage certificate based mutual authentication with its dependencies"
|
||||
|
||||
!!! success "Secret storage services must support key rotation."
|
||||
|
||||
!!! success "Depending on the deployment model Encryption Keys must be backed-up in offline secured locations."
|
||||
|
||||
!!! success "Secret storage service must be in complete isolation of external network."
|
||||
|
||||
!!! success "Tessera connection strings must not be stored in clear text in configuration files. "
|
||||
|
||||
!!! success "Secret storage in cloud deployment should run under a single tenancy model."
|
||||
|
||||
!!! success "Host firewall should be enabled, inbound and outbound traffic should be limited to only vault services and restricted to consumers of those services. This includes essential host services like DNS, and NTP."
|
||||
|
||||
!!! success "Restrict remote access to Secret Storage instance to whitelisted IP addresses and enable MFA."
|
||||
|
||||
!!! success "Disable remote root access to Tessera/Secret storage hosts."
|
||||
|
||||
!!! success "Enable remote centralized logging for tessera and its dependencies."
|
||||
|
||||
!!! success "Disable core dumps in tessera host."
|
||||
|
||||
!!! success "Tessera upgrades should be using immutable strategy and frequent."
|
||||
15
mkdocs.yml
15
mkdocs.yml
|
|
@ -24,8 +24,19 @@ nav:
|
|||
- Raft: Consensus/raft.md
|
||||
- Istanbul: Consensus/istanbul-rpc-api.md
|
||||
- Transaction Processing: Transaction Processing/Transaction Processing.md
|
||||
- Security:
|
||||
- Security & Permissioning: Security/Security & Permissioning.md
|
||||
- Quorum Security Framework:
|
||||
- Overview: Security/Framework/Overview.md
|
||||
- Quorum Network:
|
||||
- Consortium: Security/Framework/Quorum Network Security/Consortium.md
|
||||
- Quorum Node:
|
||||
- Overview: Security/Framework/Quorum Network Security/Nodes.md
|
||||
- Permissioning:
|
||||
- Network Permissioning: Security/Framework/Quorum Network Security/Nodes/Permissioning/Network Permissioning.md
|
||||
- Transaction Manager: Security/Framework/Quorum Network Security/Transaction Manager.md
|
||||
- Operational Considerations: Security/Framework/Quorum Network Security/Opertional Considerations.md
|
||||
- Decentralized App:
|
||||
- Frontend: Security/Framework/Decentralized Application/Frontend Components.md
|
||||
- Smart Contracts: Security/Framework/Decentralized Application/Smart Contracts Security.md
|
||||
- Privacy:
|
||||
- Tessera:
|
||||
- What is Tessera: Privacy/Tessera/Tessera.md
|
||||
|
|
|
|||
Loading…
Reference in New Issue