Drucksache: Windows Developer 1.18 - Sicherheit von Kryptoverfahren
Im Windows Developer 1.18 ist ein Überblick über den aktuellen Stand der Sicherheit in der Kryptographie erschienen: Welche Kryptoverfahren und Schlüssellängen sollte man verwenden, welche sollte man meiden?
Im Windows Developer 7.17 [1] haben Sie erfahren, welche Krypto-Verfahren vor Angriffen durch Quantencomputern sicher sind. Falls die irgendwann leistungsstark genug für den produktiven Einsatz sind müssen Sie zu diesen Verfahren wechseln. Aber wie sieht es denn mit der Sicherheit der aktuell genutzten Verfahren aus?
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 immer nur ein Zeitschloss, irgendwann kann sie gebrochen werden. Und das 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?
Das gleiche gilt sinngemäß für die genutzten Implementierungen. Dass Sie alle veröffentlichten Patches zügig installieren sollten versteht sich ja von selbst. Darüber hinaus sollten Sie aber auch darauf achten, ob evtl. eine Schwachstelle in oder ein Angriff auf eine von Ihnen genutzte Implementierung veröffentlicht wird, für die es (bisher) keinen Patch gibt, und notfalls nach einem Workaround suchen.
Und hier noch die Links und Literaturverweise aus dem Artikel:
- [1] Carsten Eilers: "Auch übermorgen noch sicher"; Windows Developer 7.17
- [2] Carsten Eilers: "Verfahren der Kryptographie, Teil 8: RSA"
- [3] RSA Laboratories: "RSA-768 is factored!" (auf archive.org)
- [4] 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"
- [5] Bundesamt für Sicherheit in der Informationstechnik: "BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen"
- [6] Carsten Eilers: "Verfahren der Kryptographie, Teil 6: Der Advanced Encryption Standard (AES)"
- [7] Carsten Eilers: "Verfahren der Kryptographie, Teil 5: Betriebsarten für Blockchiffren"
- [8] Carsten Eilers: "Verfahren der Kryptographie, Teil 14: Hashfunktionen - Einführung"
- [9] Carsten Eilers: "Verfahren der Kryptographie, Teil 16: SHA-2 ist noch für einige Jahre sicher"
- [10] Carsten Eilers: "Verfahren der Kryptographie, Teil 17: SHA-3 steht als Alternative und Ersatz bereit"
- [11] Bundesnetzagentur: Festlegung geeigneter Algorithmen
- [12] Algorithmenkatalog 2017, zu finden als "BAnz AT 30.12.2016 B5" auf der Website des Bundesanzeigers
- [13] RFC 7465: Prohibiting RC4 Cipher Suites
- [14] Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering, Jacob Schuldt: "On the Security of RC4 in TLS and WPA"
- [15] Microsoft: "Security Advisory 2868725: Recommendation to disable RC4"
- [16] 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
- [17] Mathy Vanhoef, Frank Piessens: "RC4 NOMORE (Numerous Occurrence MOnitoring & Recovery Exploit)"
- [18] Bruce Schneier; Schneier on Security: "New Cryptanalytic Results Against SHA-1"
- [19] 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"
- [20] Marc Stevens, Pierre Karpman, Thomas Peyrin: "The SHAppening: freestart collisions for SHA-1"
- [21] Andrew Whalley; Google Security Blog: "SHA-1 Certificates in Chrome"
- [22] J.C. Jones; Mozilla Security Blog: "The end of SHA-1 on the Public Web"
- [23] Microsoft Security Advisory 4010323: "Deprecation of SHA-1 for SSL/TLS Certificates in Microsoft Edge and Internet Explorer 11"
- [24] Apple: "Move to SHA-256 signed certificates to avoid connection failures"
- [25] SHAttered
- [26] 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" - [27] Elie Bursztein; DEF CON 25: "How we created the first SHA-1 collision and what it means for hash security" (Video auf YouTube)
- [28] Carsten Eilers: "Verfahren der Kryptographie, Teil 18: Angriffe auf Hash-Funktionen"
- [29] Openwall: "Modern password hashing for your software and your servers"
- [30] Niels Provos, David Mazières; USENIX 99: "A Future-Adaptable Password Scheme"
- [31] Wikipedia (englisch): "bcrypt"
- [32] Tarsnap: "The scrypt key derivation function"
- [33] CynoSure Prime: "320 Million Hashes Exposed"
- [34] Jake Kambic; Black Hat USA 2016: "Cunning with CNG: Soliciting Secrets from Schannel" (Video auf YouTube)
- [35] Jake Kambic; DEF CON 24: "Cunning with CNG: Soliciting Secrets from Schannel" (Präsentation als PDF, Paper als PDF, Video auf YouTube)
Trackbacks
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 3.18 - Sicherheitskonzepte in der WCF
Vorschau anzeigen