Dipl.-Inform. Carsten Eilers

Die NSA hat die Entwicklung verschiedener Standards beeinflusst. Ein Pseudo-Zufallszahlengenerator enthält eine Hintertür, IPsec ist so kompliziert, das es kaum sicher implementier- und nutzbar ist, und das ist wahrscheinlich nur die Spitze eines Eisbergs an Manipulationen.

Eine Ergänzung zum Artikel

Im Artikel wird natürlich der von der NSA manipulierte Zufallszahlengenerator Dual_EC_DRBG behandelt. Der von RSA Security lange Zeit trotz bekannter Zweifel an seiner Sicherheit als Default-Generator der Krypto-Bibliothek BSAFE verwendet wurde. Dazu gibt es einige Neuigkeiten, die erst nach Redaktionsschluss bekannt wurden:

• Die vermutete Hintertür in Dual_EC_DRBG existiert tatsächlich. Jedenfalls konnten einige Forscher sie ausnutzen: In einem Laborversuch konnten sie die Verschlüsselung von TLS-Verbindungen mit Hilfe der Hintertür brechen. Dafür konnten sie allerdings nicht die (weiter geheimen) Originalwerte der Hintertür für die im Standard vorgeschlagenen Werte verwenden, sondern mussten eigene Werte berechnen und die betreffenden Parameter in den Bibliotheken passend setzen.
• Es gibt einen Entwurf für eine TLS-Erweiterung mit dem Namen "Extended Random", die den Angriff weiter erleichtern würde. Entwickelt wurde sie von Margaret Salter von der NSA und Eric Rescorla, der jetzt als Mitarbeiter von Mozilla an der Weiterentwicklung des TLS-Standards arbeitet.
• RSA Security hat außer Dual_EC_DRBG auch "Extended Random" in BSafe integriert. Obwohl das über den Entwurf-Status nie hinaus gekommen ist. Die Erweiterung wurde allerdings auch nicht verwendet. Aber trotzdem vor 6 Monaten ausgeschaltet? Irgendwie ist das alles etwas mysteriös. Richtig geheimnisvoll. Genau so, wie man es bei einem Geheimdienst wie der NSA wohl erwarten darf.

Links und Literaturverweise

Und hier noch die Links und Literaturverweise aus dem Artikel:

• [1] Carsten Eilers: "Kryptografie im NSA-Zeitalter - Teil 1: Wie sicher sind symmetrische Verfahren noch?", Entwickler Magazin 1.14
• [2] Carsten Eilers: "Kryptografie im NSA-Zeitalter - Teil 2: Wie sicher sind asymmetrische und hybride Verfahren noch?", Entwickler Magazin 2.14
• [3] Daniel J. Bernstein: "Curve25519: A state-of-the-art Diffie-Hellman function"
• [4] OpenSSH: Changes since OpenSSH 6.4
• [5] Ed25519: high-speed high-security signatures
• [6] NIST Special Publication (SP) 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators (PDF, Version vom Januar 2012)
• [7] Berry Schoenmakers, Andrey Sidorenko: "Cryptanalysis of the Dual Elliptic Curve Pseudorandom Generator"
• [8] Daniel R. L. Brown, Kristian Gjøsteen: "A Security Analysis of the NIST SP 800-90 Elliptic Curve Random Number Generator"
• [9] Dan Shumow, Niels Ferguson: "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng" (PDF)
• [10] Matthew Green: "The Many Flaws of Dual_EC_DRBG"
• [11] FIPS 140-2 - Security Requirements for Cryptographic Modules (PDF)
• [12] Steve Marquess, Mailingliste openssl-announce: "Flaw in Dual EC DRBG (no, not that one)"
• [13] RSA BSAFE
• [14] Joseph Menn, Reuters: "Exclusive: Secret contract tied NSA and security industry pioneer"
• [15] RSA Security: RSA Response to Media Claims Regarding NSA Relationship
• [16] Nicole Perlroth, Jeff Larson, Scott Shane; New York Times: "N.S.A. Able to Foil Basic Safeguards of Privacy on Web"
• [17] James Ball, Julian Borger, Glenn Greenwald; The Guardian: "Revealed: how US and UK spy agencies defeat internet privacy and security"
• [18] Jeff Larson, Nicole Perlroth, Scott Shane; ProPublica: "Revealed: The NSA’s Secret Campaign to Crack, Undermine Internet Security"
• [19] Nicole Perlroth, New York Times: "Government Announces Steps to Restore Confidence on Encryption Standards"
• [20] NIST: Supplemental ITL Bulletin for September 2013 (PDF)
• [21] Kim Zetter, Wired: "RSA Tells Its Developer Customers: Stop Using NSA-Linked Algorithm"
• [22] Matthew Green: "RSA warns developers not to use RSA products"
• [23] NIST, Office of the Director: "Cryptographic Standards Statement"
• [24] NIST: SP 800-90 Arev1-B-C - DRAFT Draft SP 800-90 Series: Random Bit Generators
• [25] NIST initiating Review of Cryptographic Standards Development Process
• [26] RFC 4301 - Security Architecture for the Internet Protocol
• [27] Niels Ferguson, Bruce Schneier: "A Cryptographic Evaluation of IPsec"
• [28] John Gilmore: "Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN""
• [29] Counterpane Labs: CMEA Cryptanalysis
• [30] Microsoft Security Advisory (2880823) - Deprecation of SHA-1 Hashing Algorithm for Microsoft Root Certificate Program
• [31] Amerk, Windows PKI blog: "SHA1 Deprecation Policy"
• [32] William Peteroy, Security Research & Defense Blog: "Security Advisory 2880823: Recommendation to discontinue use of SHA-1"
• [33] Microsoft Security Advisory (2862973) - Update for Deprecation of MD5 Hashing Algorithm for Microsoft Root Certificate Program
• [34] NIST Computer Security Division - The SHA-3 Cryptographic Hash Algorithm Competition, November 2007 - October 2012
• [35] The Keccak sponge function family
• [36] NIST Computer Security Division - SHA-3 WINNER
• [37] John Kelsey: "SHA3 - Past, Present, and Future" (PDF)
• [38] Keccak-Entwickler: "Yes, this is Keccak!"
• [39] Bruce Schneier: "Will Keccak = SHA-3?"
• [40] John M. Kelsey: "Moving forward with SHA3" (PDF)
• [41] European Union Agency for Network and Information Security (ENISA): "Algorithms, Key Sizes and Parameters Report"
• [42] Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen: "Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen)"
• [43] NIST Special Publication (SP) 800-57: Recommendation for Key Management – Part 1: General (Revision 3) (PDF)
• [44] BetterCrypto*org
• [45] BetterCrypto*org: "Applied Crypto Hardening" (PDF)

Carsten Eilers