Schon ausgelaufen

Am 13.04.2024 um 11:40 schrieb Hergen Lehmann:

Braucht man oft nicht, oft reicht vorhandener ROM-code. Dafür gibt es etliche Tools:

Ich bin mir sicher daß auch für das Reverse Engineering von Silizium entsprechende Tools existieren. Ken Shirriff hat da auch schon einiges vorgezeigt.

Bernd

Marc Haber, 2024-04-10 08:37:

Das Apps exakt genauso sicher sind, wie ChipTAN, hat auch niemand behauptet. Das braucht aber auch nicht jeder immer und überall so.

Auch bei Apps können sich Banken nicht im Missbrauchsfall nicht pauschaö darauf berufen, dass die Umgebung unsicherer ist und man deshalb mit unerwünschten Transaktionen leben muss, für die niemand haftbar ist.

Die Bedeutung ist: justieren, optimieren, manipulieren, ... Ich habe keinen Bedarf, dieses Wort anzuwenden - weil zu ungenau, schwurbelnd.

Das Gerät wird weder verschwurbelt noch frobnifiziert. Das, was die ING dazu schreibt - die Realität - habe ich längst gepostet.

Das Gerät selbst initialisiert sich intern selbst. Vor Eintritt in die main()-Funktion und innerhalb dieser Funktion vor der Hauptschleife. Im Regelfall befindet sich Gerät im Scan-Modus. Durch Scannen einer Grafik erhält das Gerät Kommandos und Daten. Dafür stehen 100 Bytes zur Verfügung.

Die Bedienungsanleitung hat sich geändert. Aktuell gilt ein Einmalpaßwort (SMS), damals (2022) habe ich offenbar eine iTAN eingegeben.

Ich antwortete auf den Satz: "Die Daten zur Initialisierung des Gerätes können auf dem Postweg kopiert worden sein.". Kopieren auf dem Postweg wäre nämlich irrelevant.

Der Inhalt enthält alle wichtigen und entscheidenden Meilensteine, die gemeinhin für Beurteilungen und Einschätzungen als anerkannte Grundlage verwendet werden. Der Inhalt ist folglich von Wert und zutreffend.

Daß Glitching in irgendwelchen Zusammenhängen täglich verwendet wird, ist möglich. Daß Glitching im hiesigen Zusammenhang nützlich ist und zum Ziel führt, ist ausgeschlossen. Zudem steht oben 'mitunter durch "Glitching" reaktivieren'. Ich hatte bereits ausgeführt, daß das Einmalpaßwort nur nach Login im bestimmten Konto wirkt. Folglich ist ein Kopieren auf dem Postweg hier vollkommen nutzlos.

Doch, wenn er im hiesigen Zusammenhang erfolgreich sein soll. Es kann sogar sein, daß das Ziel hier unmöglich ist, es praktisch zu erreichen.

Wunschdenken. Ich bin recht sicher, daß dies im hiesigen Zusammenhang nicht erfolgreich sein kann. Es ist bisher auch undefiniert, welche Ziele erreicht werden sollen.

Nein, es ist außerordentlich stark wider die Realität! Ich habe eine zweistellige Anzahl von solchen Algorithmen implementiert. Nur DRAGON hat hier statische Tabellen. Das bedeutet, man muß alle solche Algorithmen bis ins Kleinste kennen, um weiterzukommen.

Ich selbst würde bei Sicherheitssoftware diese unanalysierbar gestalten. Solches tat ich bereits konkret.

Schon möglich. Aber dann werden viele solche Projekte wegen des Wissens frühzeitig abgebrochen.

Es gibt doch Signalverarbeitende und Datenverarbeitende ICs, die gar keine interne Prozessor-Struktur haben, gar nicht programmierbar sind.

Die Datenlängen sind im hiesigen Zusammenhang außerordentlich kurz. Da kommt es nicht zu einer signifikanten Anzahl von Runden.

RABBIT produziert beispielsweise durch einen Durchlauf 128 Bit Output. Das längste Datum hier erreicht diese Länge nicht.

Nein, ein Erfolg wird gar nicht vorkommen. Die Teilnehmer sollten sich mal klarmachen, was dieser TAN-Generator konkret macht. Er liest eine Punkte-Grafik und generiert da heraus eine 7-stellige TAN. Das Lesen und Umwandeln der Grafik ist nicht kryptographisch.

Nein, die ING kann das so programmieren lassen, wie sie will bzw. wie der Programmierer aufgrund des Lastenheftes es will. Es muß doch keinen privaten Schlüssel geben. Ich erhielt kein solches Farbcodefeld, sondern ich gab eine iTAN ein (Einmalpaßwort), um mit der Aktivierung starten zu können.

Über die Programmierschnittstelle wird der Code geschrieben. Das RAM kann darüber nicht gelesen werden. Ich bin nicht sicher, ob über die JTAG-Schnittstelle das RAM gelesen werden kann.

Mein Satz mit der Wahrscheinlichkeit ist hier aus dem Zusammenhang gerissen. Ein Vorposter hatte von geringer Code-Größe gesprochen, und daß deshalb schädliche Aktionen leicht seien.

Das wird kaum den hier besprochenen Generator betreffen.

Ja. Und was hat man davon konkret? Ich wiederhole: Der Generator liest nach Konto-Login eine Grafik und gibt eine 7-stellige TAN aus. Mehr nicht.

Auch für die Chips in meinem Generator?

Du mißinterpretierst meinen Satz. Ich habe viel konkrete Praxis-Erfahrung zum Thema. Viele andere haben keine solche, sondern formulieren oft viele blumige Worte (Theorie).

Es gibt viele Krypto-Algorithmen, die in neuerer Zeit entwickelt wurden. Du erzählst hier auswendig Gelerntes.

Daß das leicht herauszufinden ist, werden alle Praktiker verneinen. Beispielsweise gibt es auch mehrere verschiedene Versorgungsspannungen, wo Pins optional angeschlossen werden können. Es gibt viele ICs im Prozessor-Gehäuse, die gar keine Prozessoren sind.

Das ist kein Insiderwissen, sondern ganz offensichtliches Wissen, das andere jedoch gar nicht bemerkt und bedacht haben. Beispielsweise wird es keine vielen durchlaufenen Runden geben, sondern eher eine Runde.

Im Zusammenhang mit PhotoTAN habe ich bisher Solches nicht gelesen.

Du verstehst mal wieder gar nichts.

--

---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Nahezu alle heute verwendeten Verfahren basieren auf asymmetrischer Kryptografie. Du blamierst Dich erheblich.

--

---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Es ist nicht kryptografisch. Der beschriebene Vorgang erfolgt nicht durch kryptographische Algorithmen.

Ich blamiere mich überhaupt nicht. Du scheinst keine Ahnung von der Arbeit eines Entwicklungsingenieurs zu haben.

Daß die ING eine unterschiedliche, ING-spezifische Software hat, erkennt man allein daran, daß der Generator nur bei der ING funktioniert. Auch alle Verfahren damit sind stark unterschiedlich und lassen spezifische Software erkennen.

ACK (wie so soft eben)

Die hast du ja offenkundig noch weniger. Aber was Wunder, so völlig ohne Ausbildung, noch nichtmal ein Studium geschafft

Das ist nicht das Problem

Auch das ist nicht das Problem. Auch wenn es für den Kunden nicht wirklich darauf ankommt, weil ja von Gesetzes wegen allein die Bank haftet, wenn deren Authorisierungsverfahren für das angebotene Online-Banking gebrochen und von Dritten missbraucht wird, so ist doch von weitem schon ersichtlich, dass du allzu naive, völlig realitatsfremde Vorstellungen von dem hast, was man unter sicheren kryptografischen Verfahren versteht. Freilich mag eine Bank ein unsichereres Verfahren für die Online-Authentisierung von Transaktionen wählen, wenn sie davon ausgeht, dass das eventuelle Mehr an Kunden die Verluste durch stärkeren Missbrauch aufwiegen wird, wenn denn das sicherere Verfahren als allzu umständlich und kundenunfreundlich eingestuft würde

MfG Rupert

Am 14.04.2024 um 14:00 schrieb Rupert Haselbeck:

[...]

Ich kann mich noch gut erinnern, daß praktisch alle Kreditkartenemittenten abgewunken haben, als wir (als Hersteller) Kartenchips angeboten hatten. Gegenüber der aktuellen Mißbrauchsumme lohne sich das schlicht nicht...

Eric Bruecklmeier schrieb:

Ja, eine rein wirtschaftliche Betrachtungsweise, wie im richtigen Leben völlig normal. Selbst wenn die aktuell verwendeten Verfahren nicht das absolute Non-plus-ultra der denkbaren Sicherungsverfahren darstellen mögen (wenn die hier in der NG angetretenen Krypto-Autoritäten denn recht haben sollten), so spielt das keine Rolle, wenn sie nur sicher genug sind, um keinen Missbrauch zu gestatten. Zumindest keinen Missbrauch, der die Kosten besserer Verfahren aufwiegen würde.

Und aktuell ist von erfolgreichen Versuchen des Missbrauchs von Online-Banking zum Zwecke des Betrugs nichts zu hören. Das Fälschen papierener Überweisungsaufträge ist nach wie vor deutlich einfacher als jedes noch so primitive Online-Verfahren zum Beauftragen einer Überweisung auf böser Buben Konten.

MfG Rupert

Einer aus der Gruft: DES & S-Boxen. Aktuell hat aber auch Rijndael (Basis für AES) S-Boxen ... allerdings muss man nicht die statischen nehmen.

*prust* Alles eine Frage der Fähigkeiten, Erfahrung und Motivation des Analyseteams. "Die anderen sind eh doof" ist keine erfolgreiche Sicherheits- strategie.

Schonmal was von Kerckhoffs' Prinzip gehört? Eines der Grundprinzipien soliden Designs im Krypto/Security-Bereich.

Man liest sich, Alex.

In dieser NG ist der Irrsinn ausgebrochen. Leute, die keine Krypto-Algorithmen implementiert haben, weisen anderen Leuten, die viele Krypto-Algorithmen erfolgreich implementiert haben, vollkommene Unkenntnis zu allem zu ("völlig ohne Ausbildung"), insbesondere zu Kryptographie.

Dabei ist der sprachliche Ausdruck ekelhaft blumig, künstlich und verlogen, wie von einem abgebrochenen Poeten, und vollkommen unglaubwürdig.

Mit S-Boxen hatte ich bisher in nur einem Krypto-Algorithmus zu tun - dem Spritz-Algorithmus.

Ich kann eine Software-Quelle derart gestalten, daß eine erfolgreiche Analyse des Maschinen-Codes beispielsweise um den Faktor 50 länger dauert. Da wird dann meist vor einem Erfolg abgebrochen.

Beispielsweise kann ich ein Programm ganz ohne statische Daten schreiben. Diese nichtstatischen Daten verhalten sich aber so, als seien es statische Daten. Obwohl dieses Programm bei normaler Programmierung viel statische Daten braucht.

Es gibt die Wörter 'Stören' und 'Täuschen'. Wird man gestört, erkennt man, daß man gestört wird. Wird man getäuscht, erkennt man nicht, daß man getäuscht wird. Dies kann als einer der Leitsätze angesehen werden.

Nein; ich lehne es ab, Dinge auswendig zu lernen. Das bedeutet, es kann sein, daß ich dieses Prinzip kenne, jedoch nicht unter dieser Bezeichnung.

Ich habe soeben in Wikipedia festgestellt, daß ich dieses Prinzip bereits viele Jahre kenne.

Beispiel: Vorstehend habe ich offen und ausgedehnt, mit vielen Beispielen, die Funktionsprinzipien erläutert. Das schadet aber gar nichts, weil es allein auf die dort verwendeten Schlüssel ankommt.

"Implementiert" im Sinne von "einen Algorithmus in ein Programm gegossen" setzt das Verständnis der zugrundeliegenden Kryptographie nicht voraus; aus der erfolgreichen Implementation ein kryptographisches Verständnis zu begründen ist ein Fehlschluß.

Thomas Prufer

Der "Damals, vorm Kriech" Standard (DES) und der aktuelle Standard (AES) (wobei letzterer seit Jahren dedizierte CPU-Unterstützung sowohl bei amd64 als auch aarch64 Architekturen hat) sind Dir noch nicht über den Weg gelaufen, aber eine eher obscure Variante von RC4 schon? Interessante Auswahl.

Das kann man schon so machen und seine Zeit und verwurstelte Programmierung investieren, weil man Grundprinzipien der Sicherheit nicht verstanden hat. Sinnvoller ist es, die Zeit in die _Korrektheit_ der Implementation zu investieren.

Sei Dir da mal nicht so sicher. Es gibt genug kompentente Leute, die kein Problem haben, _viel_ Zeit in sowas zu investieren. Schon mehrere "unknackbare" Sicherheitssysteme die auf "supergeheimen" Algorithmen basierten wurden so aufgemacht.

[Unfug gelöscht]

*prust*

Das ist jetzt nicht Dein Ernst, oder?

Man liest sich, Alex.

Daß Du dich da weitgehend irrst, zeigt die folgende typische Dokumentation, die ich zur Implementation (in C) benutzte:

Dann arbeite einmal die vorstehende 30-seitige PDF durch. Diese PDF ermöglicht eine Implementation des Rabbit-Algorithmus und stellt in _Kurzform_ ein Cipher-Lehrbuch zu Kryptographie dar.

Ich kenne durch meine vielen Implementationen anhand von solchen Dokumentationen das Wesen der Kryptographie und weiß, warum jeder Algorithmus das vorgibt, was er vorgibt. Ich kenne folglich die Gründe der Implementations-Details und wie sie wirken.

1 Introduction 3 2 Stream Cipher Specification 3 2.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Key Setup Scheme . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 IV Setup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Next-state Function . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Counter System . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6 Extraction Scheme . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7 Encryption/decryption Scheme . . . . . . . . . . . . . . . . . 7 3 Hidden Weaknesses 7 4 Security Properties 7 4.1 Key Setup Properties . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 IV Setup Properties . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Period Length . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Partial Guessing . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5 Algebraic Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6 Correlation Attacks . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7 Differential Analysis . . . . . . . . . . . . . . . . . . . . . . . 15 4.8 Statistical Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5 Strengths and Advantages 17 5.1 Compact design . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6 Design Rationale 18 6.1 Key and IV setup . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2 The g-function . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3 The counter system . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4 Symmetry and Mixing . . . . . . . . . . . . . . . . . . . . . . 19 7 Computational Efficiency 20 7.1 Software Performance . . . . . . . . . . . . . . . . . . . . . . 20 7.2 Hardware Estimates . . . . . . . . . . . . . . . . . . . . . . . 21 7.2.1 Area optimized . . . . . . . . . . . . . . . . . . . . . . 21 7.2.2 Speed optimized . . . . . . . . . . . . . . . . . . . . . 22 8 Advice for Implementers 23 A 80-bit Key Setup 26 A.1 Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2 Proposed key setup . . . . . . . . . . . . . . . . . . . . . . . . 27 A.3 Security considerations . . . . . . . . . . . . . . . . . . . . . . 27

Es ist keine obscure Variante von RC4, sondern eine verbesserte Variante, die die Fehler von RC4 nicht aufweist. Es wird verbreitet empfohlen, RC4 nicht zu verwenden. Es wird empfohlen, stattdessen 'Rabbit' oder 'Snow3G' zu verwenden. 'Rabbit' habe ich heute in einem anderen Posting vorgestellt.

Beides ist unabhängig voneinander. Eine Korrektheit der Implementation muß stets vorliegen. Bei mir liegt sie in allen implementierten Algorithmen vor. Code, der sich gegen seine Analyse wehrt, ist optional.

Ich schrieb: "wird dann _meist_ vor einem Erfolg abgebrochen". Du meinst, es würde niemals ohne Erfolg abgebrochen?

Kein Unfug, sondern eher das Wichtigste.

Also ich habe das jetzt mal für den "Digipass 882 Hybrid - chipTAN QR und SmartTAN Photo Generator" von OneSpan NV/SA getan. Und komme auf 2uA im Standby (Display dunkel, keine Karte eingeschoben), 35mA im Betriebszustand (Display hell, Karte gesteckt, Kamera aus) und 90mA während eines Scanversuchs mit aktivierter Kamera *). Unter etwa 1.0V/Zelle nölt er rum, er möge bitte neue Batterien kriegen. AAA-Eneloops sind natürlich vollkommen problemlos einsetzbar und werden - vollgeladen - auch als voll angezeigt.

Nach ein paar Sekunden wird die Kamera ausgeschaltet, nach weiteren Sekunden die Displaybeleuchtung gedimmt und wieder ein paar Sekunden später legt sich das Gerät schlafen.

So muß das.

Volker

*) Mit einigermaßen grottigem DVM, Stromspitzen mag es dabei schon geben und fürs letzte Prozent lege ich meine Hand auch nicht ins Feuer.