Understanding Blockchain Security
2 likes5,121 views
The ITU workshop on blockchain security highlighted that the term 'blockchain' lacks a clear definition and cautioned against putting sensitive data into public blockchains due to potential long-term vulnerabilities. It proposed exploring standardization of deprecated cryptographic algorithms and authentication measures for interoperability, while also addressing weaknesses such as the irreversible nature of transactions and high costs for micropayments. Opportunities for improvement include initiatives focused on smart contracts and enhancing key attestation to reflect varying levels of assurance in blockchain transactions.
Understanding Blockchain Security
- 2. ITU Workshop on “Security Aspects of Blockchain” (Geneva, Switzerland, 21 March 2017) Understanding Blockchain Security Dr. Rolf Lindemann Nok Nok Labs, [email protected] Geneva, Switzerland, 21 March 2017
- 3. How does it work? Node 1 Who can write to? Each block contains hash of previous block What is the “previous” block? What is the “previous” block? Element to be “logged” including implicit “rules” encoded in it. The genesis Orphan blocks Orphan blocks Main chain Node 2 Node N How many nodes? Who can operate a node? Who can operate a node? Who can operate a node? What is the “previous” block? What input checks? Who can read?
- 4. Summary (1) • The term blockchain is not well defined today. • We have to be careful what to put into publicly readable blockchains. – Cryptographic algorithms get weaker over time, but the data remains in the blockchain. – Originally we thought that hashed passwords are secure, we shouldn’t repeat that mistake. – Analyzing “big data” sometimes can de-anonymize records. – People and systems fail, we need to make sure the impact of a failure remains acceptable (even from a privacy perspective). • Democracy is based on “one vote per head”. One vote per “computing power unit” is not the same as you can buy computing power with money. Rolf Lindemann, Nok Nok Labs
- 5. Summary (2) • Several enhancements of Bitcoin blockchains have been proposed. • Standardizing replacement of deprecated crypto algorithms should be investigated. • Standardizing authentication (for non-public blockchains) supports interoperability • Typically blockchain elements are signed. Sometimes it is helpful to require some “Level of Assurance” for related keys. Standardizing key attestation supports interoperability. Rolf Lindemann, Nok Nok Labs
- 6. Weaknesses • No transactions can be deleted-ever Node data volume and required processing time for verifications always increases. This is already causing intense debates. Rolf Lindemann, Nok Nok Labs
- 7. Weaknesses • Cost per transaction is relatively high – too high fir micropayments Rolf Lindemann, Nok Nok Labs
- 8. Weaknesses • Equal Rights – Assume “Miners Club A“ owns 50% computing power of the Blockchain system. – Assume “Miners Club B” owns 30% computing power of the Blockchain systems. – Assume “Miners Club C” owns 10% computing power of the Blockchain system – Assume all those Miners Clubs decided following a “My Miners Club First” strategy, i.e. whenever some other miner has successfully added a new block N they start adding new blocks ignoring block N. Rolf Lindemann, Nok Nok Labs
- 9. Opportunities • Several initiatives (Otonomos, Mirror, Symbiont, Eris/monax.io, …) look into smart contracts. • Today the rules in Bitcoin and smart contracts cannot easily reflect the strength of a signature (of the block to be written to the blockchain). But we know that in today’s world the “Level of Assurance” plays an important role. • There is a potential of adding attestation (for signing keys) to blockchain. Rolf Lindemann, Nok Nok Labs
- 10. Opportunities Node 1 Require acceptable signature Potentially require valid authentication. The genesis Element to be logged (i.e. a bitcoin transaction In some environments you might require the signing key to be kept securely or to even involve user approval for signing. So we might want to standardize key attestation for such cases. Some environments prefer private blockchains (see Hyperledger Fabric, Symbiont, …). Standardizing authentication will help interoperability.
- 11. Attack Classes Remotely attacking central servers steal data for impersonation 1 Physically attacking user devices misuse them for impersonation 6 Physically attacking user devices steal data for impersonation 5 Remotely attacking lots of user devices steal data for impersonation Remotely attacking lots of user devices misuse them for impersonation Remotely attacking lots of user devices misuse authenticated sessions 2 3 4 Scalable attacks Physical attacks possible on lost or stolen devices (3% in the US in 2013)
- 12. 12