datenritter blog

Ich bin angenehm überrascht. Die pidder-Macher sind auf meine Kritik eingegangen, und das mit geradezu historischer Offenheit und, hey, sogar humorvoll. Zu lesen unter https://www.pidder.com/blog/2010/01/eine-stellungnahme/

Ein paar Zitate und Anmerkungen... "coole Reaktion der pidder-Betreiber" ... »

pidder ist ein neuer Datenaustausch- und Single-Sign-On-Service, der sich als Gewinn für die Sicherheit anpreist. Es kommt sicher nicht überraschend, dass ich das etwas anders sehe... "Zweifel an pidder" vollständig lesen »

HDCP ist das Verfahren, mit dem HDMI-Signale verschlüsselt sind. Die ganze Technologie soll als "Kopierschutz" dienen, was an sich schon blödsinnig ist, bei digitalen Medien aber auch systembedingt gar nicht funktionieren kann. Die Industrie versucht mit HDCP einfach nur den Zugang zum Signal zu erschweren, verhindern kann sie nichts. Isotopp hat das schon mal ganz anschaulich für das Internet erklärt, und es gilt für jedes digitale Signal: Irgendwo wird es genutzt, also fällt es auch irgendwo unverschlüsselt heraus.

Im Zweifel aus dem Bildschirm.

Statt dass man die Daten direkt auf dem PC abgreift, holt man sie sich eben auf der Consumer-Hardware hinter dem Chip ab, der die Entschlüsselung macht. Das ist in einigen Fällen offenbar eine einfache Lötarbeit, der verlinkte Artikel zeigt, wie es geht.

Somit bleibt zwar eine Hürde, die die breite Masse nicht mehr überspringen kann. Vergleichsweise niedrig ist sie jedoch für Leute, die mit krimineller Absicht Urheberrechte verletzen, aber auch für Vernunftbegabte, die schlichtweg keine Lust haben, sich in der Nutzung eines Mediums, für das sie bezahlt haben, übermäßig (und damit eigentlich auch dem Geiste des Urheberrechts zuwiderlaufend) einschränken zu lassen. Vom erhöhten Stromverbrauch durch die unsinnige Verschlüsselung ganz zu schweigen.

Das Abgreifen des unverschlüsselten HDMI-Signals funktioniert vermutlich bei solchen Fernsehern, die "Fast HDMI switching" beherrschen, direkt hinter dem HDMI-4-Wege-Umschaltchip. 8 Leitungen müssen mit etwas Geschick an dünne Beinchen angelötet werden.

Der Mailman-ssls-Patch vom 18.07.2009 enthält Fehler. Mails können unverschlüsselt versandt werden, wenn der Schlüssel des Empfängers ungültig ist, obwohl im das Webinterface "Force" (erzwingen) ausgewählt wurde. Außerdem können Administratoren keine Schlüssel austauschen, beim Austragen eines Mitglieds wird der alte Schlüssel nicht gelöscht. Die ersten beiden Fehler sind mit dem folgenden Patch gegen das hier verlinkte Sourcecode-Paket leicht zu beheben:

"Mailman-ssls 2.1.12 kleinere Bugfixes" ... »

In diesem Eintrag zu Mailman-ssls ist der gepatchte Code in Version 2.1.11 verlinkt.
Hier nun die neue Version: mailman-ssls-2.1.12.tar.bz2 herunterladen.

Und noch zwei Ergänzungen:

• Ich würde beim configure-Durchlauf noch --with-mail-gid=nogroup anhängen, um Ausführungsproblemen vorzubeugen.

• Unbedingt beachten: Nur die englischen Templates der Weboberfläche wurden gepatcht. Die deutsche Oberfläche erlaubt es nicht, öffentliche Schlüssel der Listenteilnehmer einzutragen, und Mailman-ssls treibt Admins, die es auf anderen Wegen versuchen, in den Wahnsinn.

Für verschlüsselte Mailinglisten gibt es verschiedene Ansätze. Leicht ist das Leben, wenn man Mailman-ssls einsetzt. Die erweiterte Version kann all das, was die verbreitete Mailingslistensoftware Mailman auch kann, beherrscht zusätzlich aber diverse Verschlüsselungsfeatures.

Mails an die Liste werden nur noch mit dem Listenschlüssel verschlüsselt, Mailman-ssls entschlüsselt die Mails und verschlüsselt sie dann wieder für jeden Abonnenten einzeln. Nicht verschlüsselte Mails können abgelehnt werden, Empfänger ohne Schlüssel bekommen keine Kopie. Natürlich müssen die öffentlichen Schlüssel der Empfänger dem Server zur Verfügung stehen. Mailman-ssls hat dafür eine Verwaltungsfunktion.

Der große Vorteil von Mailman-ssls ist, dass die Listenteilnehmer nicht die Schlüssel aller anderen haben müssen oder gar selbst in ihren Mailprogrammen Listen pflegen. Den Komfortgewinn bezahlt man mit ein wenig Zentralismus, was auch ein Nachteil ist, denn der Server muss unbedingt absolut sicher sein, sonst könnten alle Listenmails offengelegt werden. Das heißt, er muss vor Hackerangriffen, aber auch vor physikalischem Zugriff sicher sein. Wie so oft läuft das schnell auf die Frage hinaus, ob man seinem Hoster vertraut, doch dies soll hier nicht diskutiert werden.

Erhalten bleibt auf jeden Fall der Vorteil, dass Mails auf der eigenen Festplatte verschlüsselt abgelegt bleiben, Angriffe gegen einzelne Teilnehmer einer Cryptoliste sind also nicht erfolgversprechender als sonst auch. Mailman-ssls führt aus Sicherheitsgründen standardmäßig kein Archiv und beherrscht OpenPGP-Schlüssel genauso wie X.509-Zertifikate.

Leider hat sich die Einrichtung auf einem Debian-System als etwas schwierig erwiesen, den weiten Weg zum Ziel fasse ich in diesem HowTo zusammen. "verschlüsselte Mailinglisten mit ... »

Randall Munroe bringt es mal wieder auf den Punkt:



Leider wird diese Betrachtung von Risiken oft falsch und dann als Fatalismus verstanden. "Man kann sowieso" ist eine Ausrede, die der um Sicherheit besorgte gerne von Betriebswirten und solchen, die es werden wollen, hört. Dabei wird nicht das Risiko durch eine bestimmte Gefahr mit den Kosten für die Sicherheitsmaßnahmen verglichen, wie es eigentlich korrekt wäre, sondern die Maßnnahme einfach kleingeredet.

In den meisten Fällen ist es aber so, dass die beiden verglichenen Bedrohungen voneinander unabhängig sind. Wird zum Beispiel argumentiert, dass es nichts bringt, den Hauptserver besser vor Hackerangriffen zu schützen, weil ja "sowieso" jeder "einbrechen und ihn stehlen" könnte, so ist das schlichtweg ein Fangschluss. Ein russischer Cracker wird sich nach einem gescheiterten Angriff wohl kaum "sowieso" mit dem LKW aufmachen, um den Server zu stehlen. Das Gesamtrisiko wird durch die diskutierten Maßnahmen also real verkleinert.

Etwas anderes wäre es, wenn zum Beispiel eine Verschlüsselung dort eingesetzt würde, wo die selben Datenpakete (sowieso) auch unverschlüsselt über die selbe (potentiell abgehörte) Leitung gehen. Hier wird die Sicherheit real nicht vergrößert. Solche Fälle sind selten und ziemlich nah an unmöglich.

Woran der Comic erinnert, ist trotzdem nicht völlig unerheblich, nur eben ein anderes Thema: Mit zunehmendem Wert einer Information wird die Bedrohung durch Bestechung, Erpressung und nicht zuletzt Schraubenschlüsseleinsätze größer.

Update 2009-03-08: Es gibt tatsächlich einen Fachausdruck für diese Methode. Man spricht allerdings nicht von Schraubenschlüsseln, sondern euphemistisch von "Rubber-hose cryptanalysis", also Gummischlauch-Kryptanalyse.

Gegen den von mir "Kryoattacke" getauften "Cold-Boot"-Angriff gibt es Abhilfe. Das ist nichts neues, schon im ersten Beitrag zum Thema im Februar vor einem Jahr hatte ich erwähnt, dass diverse Methoden diskutiert werden.

Die beste Methode ist wohl die jetzt "Frozen Cache" genannte. Hardwareerweiterungen und Notschalter sind nicht notwendig, der Schlüssel und weitere sensible Daten werden vielmehr in einem Bereich des CPU-Caches abgelegt, dessen Inhalt man nicht in den Arbeitsspeicher zurückschreiben lässt.

Der heise-Artikel, der heute darüber berichtet klingt anfangs ein wenig, als sei dies eine Neuigkeit, neu ist aber lediglich, dass im Blog Frozen Cache ein paar unvollständige Assemblerbefehle stehen, mit denen dies auf Intel-CPUs möglich sein soll. Heise schreibt dann auch:

Neu ist diese als Cache-as-RAM bezeichnete Methode indes nicht, bereits LinuxBIOS/CoreBoot benutzen sie, um Speicherplatz zu haben, während der Speichercontroller noch initialisiert wird.

Den heftigen Performanceverlust, den Cache-as-RAM im Normalbetrieb des PCs mit sich bringt, halten die Hacker von Frozen Cache für akzeptabel, da man den Gefriercache nur aktivieren müsse, wenn z.B. der Rechner gesperrt wird. Logisch, denn wenn ein ungesperrter Rechner entwendet wird, ist die Verschlüsselung ohnehin nutzlos. Dennoch ist das Verfahren für Server, die ständig "gesperrt" sind und ständig Leistung bringen müssen, möglicherweise sehr problematisch.

Nebenbei: Heise verwendet das nette Wort "Kühlungsattacke".

Am 10. Oktober konnte man im SC Magazine lesen, dass WPA angeblich nicht mehr sicher sei. Eine russische Firma würde die enorme Rechenleistung von nVidia-Grafikkarten-Prozessoren nutzen, um das Knacken von Passwörtern um 10.000% zu beschleunigen.

Es handelt sich übrigens um die Firma Elcomsoft, spezialisiert auf "Passwort-Rettung".

Das hat wiederum eine andere Firma, GSS, dazu veranlasst, WiFi generell für unsicher zu erklären und VPNs anzupreisen. Kristian Köhntopp fragte sich indes, wie denn die VPNs mit den gleichen Verfahren wie bei WPA sicherer sein sollen.

Bei Slashdot hat man am 12. Oktober richtig gerechnet: Eine Beschleunigung um 10.000% bedeutet ungefähr* Faktor 100. Nicht mehr. Und das bei einer Brute-Force-Attacke. Die ist bei schwachen Passwörtern schon immer erfolgversprechend gewesen, sonst eher nicht.

Das ganze ist also nichts, was man durch mehr konventionelle Rechenleistung, z.B. einen kleinen Cluster nicht auch erreichen könnte. Bruce Schneier schreibt dazu dann auch gewohnt deutlich:

Yes, weak passwords are weak -- we already know that. And strong WPA passwords are still strong. This seems like yet another blatant attempt to grab some press attention with a half-baked cryptanalytic result.

Thema durch.


(* Da bin ich pingelig: Beschleunigung um 10.000%, also um die 100fache Leistung, bedeutet auf das 101fache. Beschleunigung auf 10.000% wäre hingegen auf das 100fache. Ich gehe davon aus, dass auch im Englischen so unterschieden wird.)

Laut einem Bericht des SC Magazine hat der England and Wales Court of Appeal offenbar entschieden, dass Angeklagte Schlüssel, die sie zur Verschlüsselung beschlagnahmten Materials verwendet haben, preisgeben müssen.

Dabei ist nicht klar, ob es sich um die Schlüssel, die zugehörigen Passwörter oder beides handelt. In Deutschland besteht jedenfalls keine Mitwirkungspflicht eines Verdächtigen — hier muss man weder (den Standort von) Material noch Wissen preisgeben, wenn man sich selbst damit belasten könnte. Beides fällt unter das Zeugnisverweigerungsrecht.

Doch die erstaunliche Begründung der englischen Richter lautet:

an encryption key is no different than a physical key and exists separately from a person's will.

Hat die Existenz einer Sache in Großbritannien besondere rechtliche Implikationen?

Der folgende Abschnitt deutet darauf hin, dass es nicht um einen Schlüssel, sondern sogar um ein Passwort ging:

when the second man was arrested police saw he had partially entered an encryption key into a computer. In its ruling, the appeals court said an encryption key is no different than a physical key and exists separately from a person's will.

Den Beschuldigten drohen nun bis zu zwei Jahren Gefängnis, in Fällen der "nationalen Sicherheit" bis zu fünf Jahre. Unabhängig davon, ob die Richter nun ein Passwort oder einen Schlüssel meinten, oder beides, oder ob sie beides nicht unterscheiden konnten (was durchaus vorstellbar wäre) oder wollten, ist diese Entscheidung unsinnig. Ein Verdächtiger muss nur behaupten, er habe den Schlüssel gelöscht oder das Passwort vergessen — beides ist nicht widerlegbar, kann also eigentlich auch nicht bestraft werden.

Hinzu kommt, dass eine Strafe für das "Vergessen" des Schlüssels in einem Rechtsstaat niemals so hoch sein kann, wie die für ein wirkliches Verbrechen. Im Zweifel kommt man also immer noch gut davon.