Dipl.-Inform. Carsten Eilers

Ein schmaler Grat

Welche Kryptoverfahren sollte man verwenden bzw. meiden?

Der erste Artikel ist ein Überblick über den aktuellen Stand der Sicherheit in der Kryptographie: Welche Kryptoverfahren sollte man verwenden bzw. meiden?

Die Auswahl an Krypto-Verfahren ist, sofern man sich auf bekannte Algorithmen beschränkt, recht übersichtlich. Einige dieser bekannten Algorithmen sollte man inzwischen aber nicht mehr verwenden, da sie inzwischen gebrochen wurden. Und dann gibt es da noch einige weitere Punkte zu beachten...

Krypto-Verfahren sind nicht für die Ewigkeit gemacht. Irgendwann findet jemand einen Weg, um sie auszuhebeln. Oder die Rechenleistung aktueller Computer ist groß genug, um ursprünglich unberechenbar erscheinende Probleme doch zu lösen.

Eine Verschlüsselung ist daher nur ein Zeitschloss, irgend wann kann sie gebrochen werden. Und das gleiche gilt sinngemäß auch für alle anderen Anwendungen von Kryptografie. Weshalb z.B. die Vorgaben der Bundesnetzagentur für die qualifizierte digitale Signatur jährlich an die aktuelle Entwicklung angepasst werden. Ehemals sichere Algorithmen und Schlüssellängen werden gestrichen, neue kommen dazu.

Daher ist es wichtig, die von eigenen Projekten genutzten Kryptoverfahren und Parameter regelmäßig, z.B. jährlich, auf ihre Sicherheit zu prüfen. Und ggf. auch außer der Reihe auf aktuelle Entwicklungen wie z.B. SHAttered zu reagieren. Wann haben Sie das letzte Mal die Sicherheit der von Ihnen verwendeten Kryptoverfahren und ihrer Parameter geprüft?

Und hier noch die Links und Literaturverweise aus dem Artikel:

• [1] Carsten Eilers: "Verfahren der Kryptographie, Teil 8: RSA"
• [2] RSA Laboratories: "RSA-768 is factored!" (auf archive.org)
• [3] Cryptology ePrint Archive: Report 2010/006 - Thorsten Kleinjung, Kazumaro Aoki, Jens Franke, Arjen Lenstra, Emmanuel Thomé, Joppe Bos, Pierrick Gaudry, Alexander Kruppa, Peter Montgomery, Dag Arne Osvik, Herman te Riele, Andrey Timofeev, Paul Zimmermann: "Factorization of a 768-bit RSA modulus"
• [4] Bundesamt für Sicherheit in der Informationstechnik: "BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen"
• [5] Carsten Eilers: "Verfahren der Kryptographie, Teil 6: Der Advanced Encryption Standard (AES)"
• [6] Carsten Eilers: "Verfahren der Kryptographie, Teil 5: Betriebsarten für Blockchiffren"
• [7] Carsten Eilers: "Verfahren der Kryptographie, Teil 14: Hashfunktionen - Einführung"
• [8] Carsten Eilers: "Verfahren der Kryptographie, Teil 16: SHA-2 ist noch für einige Jahre sicher"
• [9] Carsten Eilers: "Verfahren der Kryptographie, Teil 17: SHA-3 steht als Alternative und Ersatz bereit"
• [10] Bundesnetzagentur: Festlegung geeigneter Algorithmen
• [11] Algorithmenkatalog 2017, zu finden als "BAnz AT 30.12.2016 B5" auf der Website des Bundesanzeigers
• [12] RFC 7465: Prohibiting RC4 Cipher Suites
• [13] Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering, Jacob Schuldt: "On the Security of RC4 in TLS and WPA"
• [14] Microsoft: "Security Advisory 2868725: Recommendation to disable RC4"
• [15] Jacob Appelbaum (@ioerror) auf Twitter: "@matthew_d_green @JoeBeOne @ln4711 RC4 is broken in real time by the #NSA - stop using it.", 6.11.2013
• [16] Mathy Vanhoef, Frank Piessens: "RC4 NOMORE (Numerous Occurrence MOnitoring & Recovery Exploit)"
• [17] Bruce Schneier; Schneier on Security: "New Cryptanalytic Results Against SHA-1"
• [18] Christophe De Cannière, Christian Rechberger, Vincent Rijmen; IAIK TU Graz: " Meaningful Collisions (for SHA-1)", Abschnitt "2. One Commonly Chosen Prefix + Partial Control over Colliding Blocks"
• [19] Marc Stevens, Pierre Karpman, Thomas Peyrin: "The SHAppening: freestart collisions for SHA-1"
• [20] Andrew Whalley; Google Security Blog: "SHA-1 Certificates in Chrome"
• [21] J.C. Jones; Mozilla Security Blog: "The end of SHA-1 on the Public Web"
• [22] Microsoft Security Advisory 4010323: "Deprecation of SHA-1 for SSL/TLS Certificates in Microsoft Edge and Internet Explorer 11"
• [23] Apple: "Move to SHA-256 signed certificates to avoid connection failures"
• [24] SHAttered
• [25] Elie Bursztein; Black Hat USA 2017: "How We Created the First SHA-1 Collision and What it Means for Hash Security"
  Elie Bursztein: "How we created the first SHA-1 collision and what it means for hash security"
• [26] Elie Bursztein; DEF CON 25: "How we created the first SHA-1 collision and what it means for hash security" (Video auf YouTube)
• [27] Carsten Eilers: "Verfahren der Kryptographie, Teil 18: Angriffe auf Hash-Funktionen"
• [28] Carsten Eilers: "Passwörter speichern, aber richtig!"; PHP Magazin 6.2013
• [29] CynoSure Prime: "320 Million Hashes Exposed"
• [30] Peter W. Shor; SIAM Journal on Computing 26/1997: "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer"
• [31] Lov K. Grover; Proceedings, 28th Annual ACM Symposium on the Theory of Computing (STOC) 1996: "A fast quantum mechanical algorithm for database search"
• [32] Markus Grassl, Brandon Langenberg, Martin Roetteler, Rainer Steinwandt; 7th International Conference on Post-Quantum Cryptography (PQCrypto 2016): "Applying Grover's algorithm to AES: quantum resource estimates"
• [33] Johannes Buchmann, Carlos Coronado, Martin Döring, Daniela Engelbert, Christoph Ludwig, Raphael Overbeck, Arthur Schmidt, Ulrich Vollmer, Ralf-Philipp Weinmann: "Post-Quantum Signatures"
• [34] Open Quantum Safe
• [35] Jennifer Fernick; Black Hat Europe 2016: "Real-World Post-Quantum Cryptography: Introducing the OpenQuantumSafe Software Project"
• [36] GitHub: open-quantum-safe/liboqs: C library for quantum-resistant cryptographic algorithms
• [37] GitHub: open-quantum-safe/openssl: Fork of OpenSSL that includes quantum-resistant algorithms and ciphersuites based on liboqs

Wenn das IoT ins Haus einzieht…

Heimautomation und Security

Der zweiter Artikel betrachtet die Sicherheit der Heimautomation. Oder besser: Deren Unsicherheit, denn sicher ist da leider wohl nur, dass sie unsicher ist.

Das IoT für „Internet of Things“ steht ist zumindest die offizielle Erklärung. Es gibt aber auch noch andere Erklärungsmöglichkeiten. Aus Sicherheitssicht ist das zum Beispiel ein „Internet of Targets“. Denn so unsicher, wie viele dieser „Things“ sind, stellen sie für alle möglichen Angreifer ein verlockendes Ziel dar.

Das Fazit ist eindeutig: Die Geräte des IoT sind gefährdet. Und gefährlich, wenn sie in falsche Hände fallen.

Da man als Benutzer kaum etwas tun kann, um eine gefährdetes IoT-Gerät zu schützen, sind die Hersteller gefordert: Sie müssen ihre Geräte sicher entwickeln und auch nach dem Verkauf durch die Korrektur von Schwachstellen vor Angriffen schützen.

Mit Belkin und Philips habe ich zwei Beispiele für hinsichtlich der Sicherheit sehr aktive Hersteller ausgewählt. Beide geben sich große Mühe, ihre Geräte sicher zu machen. Beide sind dabei auch recht erfolgreich, und trotzdem gibt es immer wieder Schwachstellen. Die aber wenigstens behoben werden, und das meist recht zügig. Andere Hersteller sehen das alles deutlich lockerer.

Tun die Hersteller nichts, bleibt eigentlich nur ein Schluss: Am besten vergessen wir das mit den intelligenten und vernetzten Geräten, bis die Hersteller sich dazu durchgerungen haben, sie sicher zu machen.

Denn außer „nicht nutzen“ gibt es für die Benutzer kaum eine Möglichkeit, um die Sicherheit eines gefährdeten IoT-Geräts zu erhöhen. Bei nur über das Netzwerk ausnutzbaren Schwachstellen könnte man auf die Verbindung mit dem Netzwerk verzichten, aber was soll man mit einem IoT-Gerät ohne I? Das läuft doch dann eigentlich auch auf „nicht nutzen“ hinaus.

Und hier noch die Links und Literaturverweise aus dem Artikel:

• [1] Carsten Eilers: "Sesam, öffne dich!"; Entwickler Magazin 4.17
• [2] Carsten Eilers: "Cyberkriminelle erobern das IoT"; Entwickler Magazin 1.17
• [3] Carsten Eilers: "Internet of (In)Security?"; Entwickler Magazin 4.14
• [4] Scott Tenaglia, Joe Tanen; Black Hat Europe 2016: "Breaking BHAD: Abusing Belkin Home Automation Devices" (Video auf YouTube)
• [5] SQLite3 Injection Cheat Sheet
• [6] Scott Tenaglia; Two Six Labs Blog: "Breaking BHAD: Remote Rooting WeMo Devices"
• [7] Scott Tenaglia; Two Six Labs Blog: "SQLite as a Shell Script"
• [8] Scott Tenaglia; Two Six Labs Blog: "Breaking BHAD: Injecting Code into the WeMo App Using XSS"
• [9] twosixlabs auf GitHub: Code from the Breaking BHAD talk at Black Hat Europe 2016
• [10] Colin O'Flynn; Black Hat USA 2016: "A Lightbulb Worm?" (Video auf YouTube)
• [11] Eyal Ronen, Colin O’Flynn, Adi Shamir, Achi-Or Weingarten: "IoT Goes Nuclear: Creating a ZigBee Chain Reaction"
• [12] AES-CCM Attack
• [13] Colin O’Flynn: "Philips Hue, AES-CCM, and more!"
• [14] Colin O’Flynn: "Getting Root on Philips Hue Bridge 2.0"
• [15] R. X. Seger: "Enabling the hidden Wi-Fi radio on the Philips Hue Bridge 2.0:"
• [16] Tristan Crispijn: "Soft Link Button for HUE Bridge"
• [17] Eyal Ronen, Colin O’Flynn, Adi Shamir, Achi-Or Weingarten; 38th IEEE Symposium on Security and Privacy: "IoT Goes Nuclear: Creating a Zigbee Chain Reaction" (Video auf YouTube, Paper siehe [11])
• [18] Lei Ji, Yunding Jian; Black Hat USA 2016: "The Risk from Power Lines: How to Sniff the G3 and Prime Data and Detect the Interfere Attack" (Video auf YouTube)
• [19] Thomas Brandstetter; Black Hat USA 2017: "(in)Security in Building Automation: How to Create Dark Buildings with Light Speed"
• [20] Lucas Lundgren; Black Hat USA 2017: "Taking Over the World Through MQTT - Aftermath"
• [21] Caleb Madrigal; DEF CON 25: "Controlling IoT devices with crafted radio signals" (Präsentation als PDF)
• [22] Zhengbo Wang, Wang Kang, Bo Yang, Shangyuan LI, Aimin Pan; Black Hat USA 2017: "Sonic Gun to Smart Devices: Your Devices Lose Control Under Ultrasound/Sound" (Website)

Carsten Eilers

Kategorien: Drucksache

Trackbacks

Trackback-URL für diesen Eintrag

Keine Trackbacks