{"id":1499,"date":"2013-09-02T08:41:52","date_gmt":"2013-09-02T06:41:52","guid":{"rendered":"http:\/\/blog.benny-baumann.de\/?p=1499"},"modified":"2013-10-02T23:26:41","modified_gmt":"2013-10-02T21:26:41","slug":"kaputt-dank-implementierung","status":"publish","type":"post","link":"https:\/\/blog.benny-baumann.de\/?p=1499","title":{"rendered":"Kaputt dank Implementierung"},"content":{"rendered":"

Irgendwie frustriert einen der aktuelle Zustand unserer Kryptographie-Softwarelandschaft. Einerseits m\u00f6chte man es dem Nutzer so einfach wie m\u00f6glich machen, andererseits aber einem Angreifer so schwierig wie m\u00f6glich. Prinzipiell sind alle hier g\u00e4ngigen Bibliotheken, sei es OpenSSL<\/a>, GnuTLS<\/a>, NSS<\/a>, NaCl<\/a> und die diversen OpenPGP-Implementierungen zwar an sich einig, wie die verschiedenen kryptographischen Verfahren umzusetzen sind, aber in den Details stecken so einige Stolpersteine, die einfach nicht sein m\u00fcssen.<\/p>\n

Bereits relativ fr\u00fch fiel mir hierbei ein Limit in allen PGP-Implementierungen auf, welches in keinem einzigen der relevanten Standards (RFC 1991<\/a>, RFC 2440<\/a>, RFC 4880<\/a>) erw\u00e4hnt wird, aber irgendwie dennoch – fast wie abgeschrieben – in jeglichen Implementierungen wie als w\u00e4re es im Standard fix festgeschrieben wieder auftaucht: Maximale Schl\u00fcssel-L\u00e4nge 4096 Bit RSA<\/a>, 4096 Bit DSA<\/a> (fr\u00fcher sogar nur 1024 Bit) und ECC basierend auf der verwendeten Kurve<\/a>. Nutzt man einen ElGamal-Subschl\u00fcssel (besser bekannt als „Signaturschl\u00fcssel f\u00fcr DSA“) wird sogar pl\u00f6tzlich nur 3072 Bit<\/a> verwendet.<\/p>\n

Nun stammen zahlreiche OpenPGP-Implementierungen aus den Urzeiten der ersten Crypto-Kriege<\/a>, in denen die Verwendung starker Verschl\u00fcsslungsalgorithmen verp\u00f6hnt und doch bitte der Generalschl\u00fcssel bei der Regierung zu hinterlegen war; aber diese Zeiten haben wir doch hoffentlich endlich hinter uns gelassen. Auch das Argument, der damals deutlich rechenleistungs\u00e4rmeren Computer – laut Moore’s Law immerhin nur ein Millionstel dessen, was vergleichbare Technik heute leistet – kann unm\u00f6glich als legitime Rechtfertigung akzeptiert werden.<\/p>\n

Ja, damals\u2122 war<\/strong> alles besser, aber die begrenzte Schl\u00fcssell\u00e4nge schon aus R\u00fccksichtnahme auf den eigenen Rechner anzuraten. Und das hat jeder halbwegs klar denkende Nutzer schon von sich aus beherzigt: Man hat damals deutlich gemerkt, dass gerade mit dem asymmetrischen Schl\u00fcssel gearbeitet wurde. Das Argument, dass man mit langen Schl\u00fcsseln also einen Denial of Service-Angriff fahren kann, stimmt somit nur bedingt. Zumal: Dann sollte sich diese Schranke doch eher an der Rechenleistung des Systems orientieren, statt f\u00fcr alle Ewigkeiten in irgendwelchen Code-Leichen zu lauern.<\/p>\n

Interessant ist mindestens bei GnuPG, dass es nicht ein solches Limit gibt, sondern gleich zwei unterschiedliche: W\u00e4hrend das eine Limit einzig bei der Schl\u00fcsselgenerierung erzwungen wird und bei 4096 Bit seit Ewigkeiten festgeschrieben ist, wird das andere Limit<\/a> nicht etwa beim Rechnen mit gro\u00dfen Zahlen, also dann wenn wirklich Zeit ben\u00f6tigt wird, gepr\u00fcft, sondern beim Lesen und Schreiben eben solcher \u00fcberlangen Zahlenkolonnen; also in dem Moment, wenn die Schl\u00fcsselgenerierung bereits tagelang Rechenleistung verbraten hat und somit nach Abschluss dieser Arbeiten das Ergebnis in die M\u00fclltonne bef\u00f6rdert.<\/p>\n

Eine andere irrwitzige Beschr\u00e4nkung dieser Kategorie findet sich in OpenSSL, wie ich leidlich feststellen musste, als ein SSL-Assessment-Test fehlschlug, beim Versuch, die 13337 Bit umfassenden DH-Parameter auszuhandeln. Nein, nicht wegen eines Timeouts, sondern wegen – gut geraten – einem fest kodierten Limit der Maximal-L\u00e4nge von 10000 Bit. Ein Limit was \u00fcbrigens an lediglich einer Stelle<\/a> definiert, und auch nur an exakt einer Stelle<\/a> gepr\u00fcft wird. Die Stelle der Pr\u00fcfung findet man in OpenSSL \u00fcbrigens auch nur anhand der Fehlermeldung, aber das ist eher ein Problem der Code-Qualit\u00e4t von OpenSSL, \u00fcber die man besser nicht reden sollte.<\/p>\n

Qualit\u00e4t liefert an dieser Stelle \u00fcbrigens auch die Implementierung von GnuPG bei der Sicherung des Private Keys, die beschr\u00e4nkt durch ein ewig niedriges Limit<\/a> von 32KiB „sicherem Speicher“<\/a> unter Linux beim kleinsten Hustenanfall mit einem halbwegs „sicheren“ Schl\u00fcssel gleich Schreikr\u00e4mpfe bekommt, das zu wenig Platz da sei. Oder anders ausgedr\u00fcckt: Entweder man vertraut seinem Rechner eh von Haus aus – dann brauch man diese Farce mit gesichertem Speicher nicht – oder man muss dieses Feature abschalten: Was einem nur in der Form gelingt, dass man ihm mitteilt, dass er doch soviel „sicheren Speicher“ initialisieren soll, dass er der Meinung ist, dass es keinen g\u00e4be und er daher mit einer Warnmeldung dennoch fortsetzt. Versucht man an der Stelle die direkte Deaktivierung, verweigert GnuPG den Dienst komplett.<\/p>\n

Ein anderes interessantes Speicherproblem hat an dieser Stelle auch Mozilla in seiner NSS-Implementierung im Angebot, was aus drei Gr\u00fcnden sehr bemerkenswert ist: 1. es ist konstant reproduzierbar, 2. es ist Abh\u00e4ngig von der Schl\u00fcssel-Operation und 3. es ist vollkommen unlogisch. Aber der Reihe nach, denn dieses Problem braucht etwas Erkl\u00e4rung. Wie einige sicherlich festgestellt haben, verwendet dieser Blog SSL. SSL<\/a> ist dieser Krypto-Foo mit Zertifikaten<\/a>, was einmal zum Absichern von 50-Dollar-Transaktionen<\/a> entworfen wurde. Nunja, eben dieses SSL wird auf diesem Server mit einem X.509-Zertifikat mit einem 8192-Bit-RSA-Schl\u00fcssel verwendet. Kein Problem, braucht 2KiB, ggf. 8KiB RAM f\u00fcr ein paar Potenzierungsoperationen, aber ist sonst nicht der Rede wert. Au\u00dfer man versucht sich mit eben jenem Schl\u00fcssel in Form eines Client-Zertifikates bei einer Website zu authentifizieren. Das f\u00fchrt reproduzierbar zu einem Out-of-Memory-Fehler, und zwar nicht erst bei 8192 Bit, sondern exakt bei allem, was mindestens ein Bit mehr als 4096 Bit RSA hat. W\u00e4re die Grenze wenigstens bei irgendetwas krummen, k\u00f6nnte man das ganze mit wirklicher Speichernot erkl\u00e4ren, wobei selbst dann das WTF bleibt, warum man nur so wenig gesicherten Speicher verf\u00fcgbar hat. Ach ja: Gleiches Zertifikat im Thunderbird f\u00fcr Email-Signaturen eingesetzt l\u00e4uft \u00fcbrigens reibungslos. Und bevor das Argument mit krummen Schl\u00fcssell\u00e4ngen kommt, sei noch erw\u00e4hnt, dass es mit 4095 Bit reibungslos funktioniert.<\/p>\n

Aber eines muss man Firefox an dieser Stelle lassen: Im Gegensatz zu diversen Apple-Produkten erh\u00e4lt man wenigstens eine klare Fehlermeldung; wenn auch keine wirklich hilfreiche. Auf Apple sieht das Ganze etwas anders aus: Hier reicht ein Besuch des Blogs in der Regel bereits aus, um Safari auf die Reise ins Nirvana zu schicken. Und da Apple an dieser Stelle eine konsistente User Experience bietet, geschieht dies konsequent auch auf iOS 6-Devices, was sich sowohl mit dem iPhone, als auch einem iTampon<\/del>Pad reproduzieren lie\u00df. Auf iOS 7 gab es zwischenzeitlich sogar einmal Besserung: Nein, die Krypto hat nicht einfach mal ihren Dienst getan, zumindest nicht so, dass ein Nutzer h\u00e4tte etwas damit anfangen k\u00f6nnen. Der Fortschritt bestand hier vielmehr darin, dass es iOS 7 geschafft hat, dem Nutzer das Zertifikat der Website zu p\u00e4sentieren, bevor es – nach dessen \u00dcberpr\u00fcfung und Akzeptanz – eine Endlos-Schleife mit Page-Reloads angetreten hat.<\/p>\n

Nun bin ich absolut kein Freund von Apple oder Safari, aber einfach nur zu sagen Safari ist hier kaputt w\u00fcrde die Sache etwas sehr stark vereinfachen. Vielmehr haben wir hier ein Problem in der Krypto-Lib von iOS am Hals, was sich auch an anderer Stelle wunderbar zeigt. Denn wir alle m\u00f6gen Mails, diese kleinen RFC-822-formatierten Text-Konglomerate die zu 90% Spam und 10% anderen Bullshit enthalten. Manchmal verirrt sich hier auch eine sinnvolle Mail darunter, was oft dadurch erkennbar wird, dass diese Mails eine Signatur tragen. Solche Signaturen sind praktisch. Manchmal findet man diese auch auf Mailing-Listen. Zu dumm nur, wenn der Mail-Client der Wahl aus Versehen immer dann abst\u00fcrzt, wenn man versucht, die Mail zu lesen, zu verschieben, zu l\u00f6schen oder anderweitig irgendetwas mit dieser Mail anzufangen.<\/p>\n

Und alle diese Dinge waren komplett von den passenden Standards gedeckelt, oder basierend auf der zugrundeliegenden Mathematik vollst\u00e4ndig legitim, was umso interessanter wird, wenn man sich einmal eine Reihe von Standards anschaut, die Rahmenbedingungen f\u00fcr diverse Verschl\u00fcsslungsverfahren festlegen. Denn wer hat sich noch nicht gewundert, warum in Public Keys bei RSA immer 65537 vorkommt (naja, au\u00dfer bei so ein paar Schl\u00fcsseln von mir) und man nicht der mathematischen Grundlage folgt, nach der e einfach nur teilerfremd zu sowohl p als auch q sein muss? Hier gibt es prinzipiell zwei Antworten, wobei die eine prim\u00e4r die Wahl der Zahl erkl\u00e4rt – was eine reine Performance-Entscheidung darstellt -, w\u00e4hrend die andere zu einem NIST-FIPS-Standard f\u00fchrt, der festlegt, dass e mindestens 65537 (zur Vermeidung von einigen Angriffen) aber maximal 2^256-1 sein darf. Womit wir an der Stelle w\u00e4ren, wo der Standard einfach keinen Sinn ergibt: Ja, man m\u00f6chte ein Limit haben, aber dieses ist prim\u00e4r dadurch begr\u00fcndet, dass bei gro\u00dfen Exponenten die Wahrscheinlichkeit f\u00fcr d < < e deutlich zunimmt; liest man hierzu die passende Literatur, ergibt sich ein sinnvolles Limit bei ungef\u00e4hr 70% des Modulus n, was selbst bei moderaten 4096er Schl\u00fcsseln bereits 2^3072-1 ergibt – AKA eine Zahl, die 10 mal so lang ist.<\/p>\n

Mangels passenden Utilities konnte ich noch nicht pr\u00fcfen, wieviel kaputte Krypto-Software den Public Exponenten als Gott-gegeben mit 65537 annimmt, aber so wie das bisher ausschaut, w\u00fcrde es mich nicht verwundern, wenn mit entsprechenden Schl\u00fcsseln noch eine ganze Menge Software den Geist aufgibt.<\/p>\n

Was mich zu meinem Punkt an dieser Stelle bringt: Wann h\u00f6ren die Leute endlich auf, die Standards w\u00f6rtlich zu implementieren, frei von jeglichem Verstand der darunterliegenden Verfahren? Ja, es ist ein absolutes Desaster, wenn man zuf\u00e4llig uninitialisierte Speicherzugriffe patcht<\/a> oder gleich die Backdoor im PRNG platziert<\/a>, aber warum muss dann bitte sch\u00f6n die Funktionalit\u00e4t k\u00fcnstlich beschr\u00e4nkt werden, nur weil der Geheimdienst des eigenen Misstrauens sonst nicht ausreichend mitlesen kann?<\/p>\n

Macht Krypto bitte endlich einmal richtig!<\/p>\n

AAAH-CHOO!<\/p>\n

\"Flattr<\/a><\/p>","protected":false},"excerpt":{"rendered":"

Irgendwie frustriert einen der aktuelle Zustand unserer Kryptographie-Softwarelandschaft. Einerseits m\u00f6chte man es dem Nutzer so einfach wie m\u00f6glich machen, andererseits aber einem Angreifer so schwierig wie m\u00f6glich. Prinzipiell sind alle hier g\u00e4ngigen Bibliotheken, sei es OpenSSL, GnuTLS, NSS, NaCl und die diversen OpenPGP-Implementierungen zwar an sich einig, wie die verschiedenen kryptographischen Verfahren umzusetzen sind, aber […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[29],"tags":[14,98,69,112,128,122,50],"class_list":["post-1499","post","type-post","status-publish","format-standard","hentry","category-software","tag-bugs","tag-developement","tag-internet","tag-kryptographie","tag-meinung","tag-rfc","tag-ssl"],"_links":{"self":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/1499","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1499"}],"version-history":[{"count":6,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/1499\/revisions"}],"predecessor-version":[{"id":1505,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/1499\/revisions\/1505"}],"wp:attachment":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1499"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1499"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1499"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}