Sicherheitsaspekte Blockchain-basierter Technologien – insecure in any Case?

Von   Prof. Dr. Hartmut Pohl   |  Geschäftsführender Gesellschafter der IT-Sicherheitsberatung   |  softScheck GmbH
29. August 2017

Mit der viel-gerühmten Sicherheit der Blockchain ist es nicht weit her: Sicher ist nämlich nur das Konzept[1]. Insbesondere die Sicherheitsqualität der Implementierung[2] muss daher durch die Identifizierung enthaltener Sicherheitslücken[3] bewertet werden.
Dies gilt für Blockchain-Funktionen wie smart Contracts, DApps, Consensus, Transaktions- und Block-Generierung und – Verwaltung und auch für Hashs, Verschlüsselung und Zufallsgeneratoren – nicht nur im ausführbaren Code, sondern bereits im Design und dann in der Implementierung. Keinesfalls reicht eine – ja nur nachträglich wirksame – Quelloffenheit des Codes aus[4]. Grundsätzlich kommen in der Implementierung mögliche Fehlerquellen in Betracht wie Anfälligkeit gegenüber Sabotage wie Distributed Denial of Service (DDoS) Attacks[5], unberechtigtes Trennen eines Nodes vom Netz und illegale Inhalte in den Transaktionen.

Die eingesetzten Hashverfahren beeinflussen das Sicherheitsniveau stark. Bitcoin benutzt doppelt gehashtes SHA-2 (SHA-256) und entspricht damit (nur) den aktuellen Empfehlungen des BSI bis 2022. Sollte die Hashfunktion gebrochen werden, so muss eine neue Softwareversion an alle Teilnehmer verteilt werden und es muss eine neue – mit einer besseren Hashfunktion neuberechnete – Blockchain gebildet werden (‚Hard Fork‘).Die vertrauenswürdige Verwaltung (Generierung, Speicherung, Löschung etc.) insbesondere der zugehörigen privaten Schlüssel inklusive deren Geheimhaltung und auch die Datensicherung z.B. für die digitale Signatur obliegen dem einzelnen Teilnehmer. Ein öffentlicher Schlüssel dient in Transaktionen als Empfangsadresse (Bitcoin).

Angriffe auf Blockchain-Systeme sind bekannt [6], [7]. Im Android-Bitcoin-Client „Bitcoin Wallet“ wurden bisher zwei Sicherheitslücken identifiziert, die auf die Zufallszahlengenerierung zurückgingen[8], [9]. Erfolgreiche Angriffe ermöglichen eigene bereits getätigte Transaktionen rückgängig zu machen oder mehrfach zu tätigen (‚double-spend‘), sowie fremde Transaktionen zu blockieren.

Erlangt ein Angreifer die Kontrolle über Teile des Netzwerks oder über den Zugriff einzelner Teilnehmer zum Netzwerk, kann dieser eine Blockchain mit alternativen neuen Blöcken präsentieren. Eine Lösung dieses Problems muss in der Implementierung berücksichtigt werden. Erforderlich ist eine große Zahl unabhängiger Teilnehmer.

Die Inhalte der Transaktionen und Blöcke sind in Kryptowährungen absichtlich für alle lesbar. Es sind Blockchain-basierte Technologien mit verschlüsselten Blockdaten denkbar; nur so könnte Vertraulichkeit erreicht werden.

Ein ganzheitlicher Schutz gegen Sabotage mit Denial of Service Angriffen ist schwer zu erreichen. Die Schutzmöglichkeiten variieren je nach eingesetzter Netzwerkstruktur.

Sichere und stabile Clients sind jedenfalls unverzichtbare Voraussetzung bei allen Teilnehmern!

In einer Blockchain kann Anonymität nicht (ohne weitere Maßnahmen) erreicht werden – sondern nur Pseudonymität. Die Blockchain und damit alle Transaktionen sind rückverfolgbar (z.B. Geldflüsse). Um als Initiator einer Transaktion beim Versand im Netz nicht seine IP preiszugeben, kann unterstützend ein Dienst wie TOR genutzt werden. Die EU plant allerdings die Identifizierung aller Nutzer[10].

An diesen Beispielen lässt sich erkennen, dass bei der Umsetzung des Konzepts Blockchain Herausforderungen auftreten, das Sicherheitsniveau insbesondere von der Implementierungsqualität /Sicherheitsqualität der Komponenten abhängt: Hinreichend ist nur ein vollständiger Security Testing Process auf der Basis der ISO 27034 mit den folgenden 5 Methoden:

  • Security Requirements Analysis,
  • Threat Modeling zur Untersuchung des Security Designs,
  • Static Source Code Analysis zur Überprüfung des implementierten Codes,
  • klassisches Penetration Testing zur Erkennung veröffentlichter Sicherheitslücken und
  • Dynamic Analysis – Fuzzing zur Identifizierung bisher nicht-erkannter Sicherheitslücken (Zero-Day-Vulnerabilities).

[1] Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf

[2] Pohl, H. et al.: Sichere Softwareentwicklung nach ISO 27034. KES 24 – 25, 5, 2014

[3] Common Vulnerabilities and Exposures. Incident CVE-2010-5139 https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139 und
Bitcoin.org: 11/12 March 2013 Chain Fork Information https://bitcoin.org/en/alert/2013-03-11-chain-fork

[4] Fefes Blog Mon Jul 3 2017 https://blog.fefe.de/?ts=a7a45c1a

[5] Giese, P.: Mysteriöse riesige BTC-Transaktionen verlangsamen Bitcoin-Netzwerk. BTC-Echo 10.3.17 https://www.btc-echo.de/mysterioese-riesige-btc-transaktionen-verlangsamen-bitcoin-netzwerk/

[6] Karagiannis, K.: Hacking Blockchain.RSA Conference San Francisco 2017 http://bit.ly/2oKP62s

[7] Blockchain Graveyard https://magoo.github.io/Blockchain-Graveyard/

[8] 55 BTC Stolen Through Security Vulnerability in Android Bitcoin Wallets. TradeBlock Aug 11, 2013 https://tradeblock.com/blog/security-vulnerability-in-all-android-bitcoin-wallets

[9] Goodin, D.: Crypto flaws in Blockchain Android app sent bitcoins to the wrong address. 5/29/2015 https://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address

[10] European Commission: Questions and Answers: Action Plan to strengthen the fight against terrorist financing. http://europa.eu/rapid/press-release_MEMO-16-209_de.htm

Prof. Dr. Hartmut Pohl ist als geschäftsführender Gesellschafter der IT-Sicherheitsberatung zuständig für taktische und strategische Sicherheitsberatung u.a. basierend auf BSI-Grundschutz, ISO 27000-Familie, COBIT, NIST SP 800, ITIL etc. inkl. Forensik

Um einen Kommentar zu hinterlassen müssen sie Autor sein, oder mit Ihrem LinkedIn Account eingeloggt sein.

21156

share

Artikel teilen

Top Artikel

Ähnliche Artikel