 Ja, schönen guten Abend. Ich bin Alexander Koch. Ich studiere Informatik an der Uni Kiel und habe diesen Sommer meine Bachelorarbeit geschrieben, über genau dieses Thema. Der Vortrag jetzt wird zuerst auf gesetzliche Rahmenbedingungen eingehen, dann auf die Umsetzung dieser Rahmenbedingungen in der Praxis. Anschließend haben wir, also mein dozent, natürlich, zusammen Produkt ausgewählt, anhand dessen dann weitere Analyse durchgeführt wurde. Da werde ich einmal zeigen, wie die bei diesem Produkt so eine Signaturforschung abläuft, was für eine Signaturtheit dabei herauskommt und welche Daten damit transferiert werden. Anschließend werde ich dann Eigenheiten aus dieser Analyse benutzen, um die ganze Geschichte anzugreifen. Dabei werde ich einmal beschreiben, wie man vorgehen muss, um eine Signaturtheit zu fälschen und zum weiteren beschreiben, wie man Zugrufe auf die transferierten Daten erhalten kann. Los geht's also mit den gesetzlichen Rahmenbedingungen. Warum haben wir überhaupt digitale Signaturen? Das ist im Prinzip eine Idee von der EU. Die haben sich gedacht, okay, wir haben jetzt die Grenzen aufgemacht. Wir können jetzt ganz einfach Wein von Frankreich nach Schweden exportieren, brauchen keine Zollkontrollen mehr. Aber um den Wein zu kaufen, muss man immer noch Verträge unterschreiben und dazu sich mit Handelspartnern treffen oder zumindest irgendwelche Notare damit beauftragen, das durchzuführen und dann die Verträge per Post umständlich durchs ganze Land schicken. Das ist zeitaufwendig, das ist kostenaufwendig, das ist alles blöd. Wir brauchen irgendwas, was man schnell über das Internet verschicken kann, was man gleichgestellt mit herkömmlichen Signaturen verwenden kann, um eben rechtsgöttige Verträge abzuschließen. Und was sie sich dann ausgedacht haben, war einfach die EU-Richtlinie 1999-93-EG, die beschreibt im Prinzip genau das, stellt irgendwelche Anforderungen und insbesondere legt die fest, dass diese digitalen Unterschriften, handschriftlichen Unterschriften gleichgestellt sind. Umzusetzen war das Ganze bis die Öli 2001, ist also schon knapp zehn Jahre alt, es sollte also genug Zeit gewesen sein, das vernünftig umzusetzen. Was dabei dann rausgekommen ist, werden wir gleich sehen. Diese EU-Richtlinie war dann von Deutschland natürlich umzusetzen, Deutschland war dann in das Ignaturgesetz und die Signaturverordnung gegossen. Die Signaturverordnung spielt für uns jetzt nicht so wirklich eine Rolle, weil die beschreibt nur irgendwelche Erweiterungen, Erweiterungen um Anforderungen an Aussteller. Also wie der Signaturgesetz nachher noch genau abläuft, sehen wir dann noch. Auf jeden Fall braucht man irgendwelche Zertifizierungsstellen, die Zertifikate ausgeben und diese Aussteller müssen halt bestimmte Anforderungen erfüllen und das macht die Signaturverordnung. Wichtig ist das Signaturgesetz. Dieses unterscheidet zwischen drei Güteklassen von elektronischen Signaturen. Es gibt einmal die einfachen elektronischen Signaturen, die haben einfach keine weiteren Anforderungen, das heißt als ich könnte einfach ein Bild mit meiner Unterschrift, einem Dokument anhängen und das einfach per E-Mail verschicken, das würde schon ausreichen als einfache Elektronische Signatur, ist natürlich überhaupt nicht fälschungssicher, weil jeder, der dieses Bild erhalten hat, der kann das Bild einfach wieder weiter verschicken und damit machen, was er will, ohne meine Einverständnis und kann damit im Prinzip in meinem Namen unterschreiben. Deshalb will man das natürlich nicht. Also gibt es die folggeschrittene elektronische Signatur, die dann weitere Anforderungen hat. Zum einen muss sie ausschließlich dem Unterzeichner zuordnet sein. Sie muss es ermöglichen, dass man anhand der Signatur herausfinden kann, wer denn jetzt unterschrieben hat. Es muss möglich sein, dass der Unterzeichner den Signatur erstellt, ohne dass da andere irgendwie beteiligt werden müssen. Also ich kann ja jetzt auch zum Beispiel auf dem Blatt Papier einfach allein unterschreiben, da brauche ich ja keine Hilfe für, wäre ja blöd, wenn ich jetzt irgendwie sagen müsste, hier helfen, um meine Signatur zu erzeugen. Und vor allen Dingen soll die eine Veränderung der unterzeichneten Datenerkennung machen, also dafür sorgen, dass eine Signatur für ein Dokument nicht auf ein anderes Dokument übertragen werden kann. Die qualifizierte elektronische Signatur ist dann die höchste Güteklasse, die hat noch weitere Anforderungen, nämlich sie muss auf einem qualifizierten Zertifikat beruhen und auf einer sicheren Signaturerstellungseinheit erstellt werden. Was das ist, sehen wir auch. Ein qualifiziertes Zertifikat ist einfach erstmal ein Zertifikat. Was ist ein Zertifikat? Ein Datensatz, der Eigenschaften bestätigt und irgendwie geprüft werden kann. Also da steht jetzt drin, Alexander Koch hat den öffentlichen Schlüssel sowieso, und damit nicht irgendwer das behauptet, obwohl es gar nicht stimmt, also mir irgendjemand einen falschen öffentlichen Schlüssel unterjubelt, bestätigt das eine vertrauenswürdige Stelle, also diese Certificate Authority, mit einer weiteren Unterschrift, die dann wieder geprüft werden kann. Das Zertifikat ist dann qualifiziert, wenn in diesem Zertifikat bestimmte Sachen enthalten sind, nämlich Ausstelle und Staat, Name des Inhabers, halt alles, was da gerade aufgelistet ist. Diese sichere Signaturerstellungseinheit soll jetzt weitere Sicherheitseinforderungen sicherstellen, und zwar soll insbesondere dafür gesorgt werden, dass Signaturen nicht gefälscht werden können, dass also die zugrunde privaten Schlüssel nur einmal auftreten können, dass sie geheim gehalten werden und das ja auch für einen in geheimen bleiben, dass sie nicht abgeleitet werden können, also angenommen jemand hat jetzt ein Signatur von mir bekommen, der soll jetzt nicht zurückrechnen können, wie war der privat Schlüssel dazu, um dann eben wieder eigene Signaturen erstellen zu können, dass sie vor Fälschungen geschützt sind und vor der Verwendung durch andere geschützt werden. Also es sind im Prinzip alle Sachen, die auf das gleiche Ziel abzielen, dass die Signatur eben einzigartig ist und nur von dem erstellt werden kann, der sehr wirklich erstellen darf. Außerdem sollen die Daten, die da signiert werden, beim Signieren nicht verändert werden und dargestellt werden können. Also wenn ich jetzt was signiere, dann soll nicht verändert werden, dass mir angezeigt wird, was ich dann signieren will, um halt zu ermöglichen, dass man nochmal berufen kann, was man denn gerade signiert und ob man das wirklich signieren will. Und wenn ich jetzt den String ABCD signieren will, dann soll ich nicht, weil es gerade passt, diesen String-Formsignieren in ABCDE verändern, sondern es soll halt wirklich genau das signiert werden, was der Signator signieren möchte. Als Fazit kann man jetzt zusammenfassen, der Gesetzgeber versucht, elektronische Signaturen gleichzustellen, in Bezug auf Rechtswirkung und Fälschungssicherheit, versucht also alles dafür zu tun, dass diese elektronischen Signaturen voller Erfolg werden und genauso natürlich benutzt werden können wie herkömmliche Signaturen. Das Ganze wird dann umgesetzt, meistens mit Prozessorschippkarten, die kann man sich vorstellen wie komplette eigenständige PCs, inhalten in der Recheneinheit Speicher und in diesem Speicher eben die Zertifikate und die privaten Schlüssel. Die Zertifikate jetzt nicht nur die des Unterzeichners, sondern auch die des Ausstellers und der Bundesnetzagrantur, also des Ausstellers des Ausstellers. Und um eben diese Prozessorschippkarten zu benutzen, braucht man zum einen eine PIN, die man eingeben muss, um halt sicherzustellen, dass man jetzt an der Stelle des Signaturschlüsseln nicht einfach die Karte klauen kann, sondern zur Karte braucht man eben diese PIN. Und weil die meisten PCs eben keine Möglichkeit haben, diese PINs zu lesen, diese Signaturkarten zu lesen, braucht man halt ein Kartenlesegerät und irgendwie eine Software, die das Ganze dann auch ansteuert. Ein Signaturvorrang läuft dann einfach so ab, man nimmt irgendwie Daten und im Daten, die steckt man in eine Haschfunktion, es kommt daraus ein haschfester Länge. Diesen Hasch verschlüsselt man dann mit dem privaten Schlüssel des Unterzeichners, der ja auf der Signaturkarte ist, also im Prinzip schickt man den Hasch an die Signaturkarte. Auf der Signaturkarte gibt es dann eben einen privaten Schlüssel, man sagt das Signaturkarte dann, hey, signe das mal, die fragt dann von allein nach der PIN. Wenn die PIN dann bestimmt wird, dann wird eben das Ganze verschlüsselt. Zusammen mit dem Zertifikat ergibt es dann eben die Unterschrift, die man dann entweder wieder mit dem Dokument zusammenpacken kann oder als getrennte Datei einfach zusätzlich zu dem Dokument verschicken kann. Wenn man als Empfänger jetzt so eine Datei bekommt, dann kann man das Ganze im Prinzip rückwärts machen, also man nimmt einen öffentlichen Schlüssel und die Signatur, guckt nach welcher Hasch kommt dabei raus und wie sehr das Dokument ausfasst, was dazu verschickt wurde. Wenn da der gleiche Haschfeld dabei rauskommt, dann weiß man eben, die Daten haben sich nicht verändert und die Signatur ist gültig. Meine Aufgabenstellung bei der Wärtschlaararbeit war jetzt zu überprüfen, inwieweit die USB-Verbindung zwischen Arbeitsplatzrecht und Kartenlise abgesichert ist. Insbesondere sollte halt geprüft werden, ob man irgendwie dazwischen kommt und das Ganze irgendwie angreifen kann, also sprich, eigene Daten signieren. Dafür braucht man natürlich ein Produkt, was wir da irgendwie angreifen konnten bzw. was wir erstmal analysieren konnten und es gibt eine ganze Reihe von möglichen Zertifizierungsdienstanbietern, es gibt eine ganze Reihe von Zertifizierungsdienstanbietern, die kann man auch auf den Seiten der Bundesnetzarventur abrufen. Bekannt sind insbesondere die Sparkassen und die Deutsche Post, also ich kenne keine Stadt in der Internetfiliale von der Sparkasse oder der Deutschen Postwehr. Die Deutsche Post hatte jetzt noch den Vorteil, dass sie ein wirkliches Komplett-Set angeboten haben, wo eben Kartenleser, Chipkarte und Software dabei war also im Prinzip das Rundum-Sorgblut-Paket, man brauchte, wir mussten das Netz gehen, sagen, hey, ich will jetzt elektronische Signaturen erstellen können, gib mir mal ein Set und dann ging es los. Dann konnte man das Antrag ausdrucken, musste noch zur Post laufen, irgendwie mit dem Post-Ident-Verfahren sicherstellen, dass man wirklich der ist, der da signieren will und dann kam zwei Wochen später irgendwie ein Päckchen, da drin war dann ein Chipkartenterminal, man sieht hier, das ist ein Klasse 2-Lese, hat also noch kein Display oder irgendwas anderes. Das wird über den USB an den Rechner angeschlossen und fällt in die Gerätenglasse der Circuit-Karten-Interface-Divices, also ganz natürlich ein Chipkarten-Ansteuerungsgerät. Die Chipkarte, die dabei ist, ist von den Finnian, auf der Chipkarte drauf ist das Betriebssystem StarCost 3.2, das hält sich an den ISO-Standard, beziehungsweise in diesem ISO-Standard 7816 definierten Kommandos, insbesondere die Kommandos des Parts 4 und des Parts 18, die relevant. Also Part 4, es sind irgendwie allgemeine Chipkartenkommandos, so was wie FileSelect oder Binary Transfer und Part 8 beschreibt dann sicher als kritische Kommandos, so was wie Computer-Digital Signature. Signature Software konnte man zwischen zwei möglichen ausfehlen. Ich habe mich hier für die erste entschieden. So ein Signature-Verfahren läuft so aus, man wählt ein Datei aus, wählt dann Signature-Verfahren aus. Ich kann es eigentlich direkt live zeigen. Also ich habe ihn in der Datei, da steht irgendwas drin. Den will ich jetzt unterschreiben. Die Anwendung registriert sich dann im Kontext-Menü und man kann dann hier über Signature-Live signieren, einfach die Datei ausfehlen zum Signieren. Jetzt kann ich hier halt dieses Signature-Verfahren auswählen. Ich kann jetzt nur diese eine Option wählen. Also mache ich das einfach mal. Jetzt kann ich mich hier entscheiden, ob ich das signierte Dokument in die Signature einbetten möchte. Das lasse ich jetzt mal bleiben. Dann möchte ich natürlich mit meiner Chipkarte signieren. Das ist jetzt nicht meine, sondern die von jemand anderem. Meine wurde am Wochenende gesperrt. Es ist auch egal. Ich habe über das Wochenende noch ein Neubesort. Attributsvertifikate sind jetzt hier nicht vorhanden. Es gibt jetzt noch ein bisschen gesetzliche Vertretung für jemanden. Also angenommen, ich möchte jetzt jemanden vertreten. Dann muss ich das natürlich irgendwie getrennt auswählen können, weil sie können das ja nicht permanent ins Zertifikat reinschreiben, dass ich immer jemanden vertrete, sondern vielleicht möchte ich auch mal was allein unterschreiben. Also es ist dann ein Zusatzzertifikat. Gibt es hier jetzt nicht. Dann gibt es hier noch so eine Übersicht und dann kann ich das fertigstellen. Ich muss meine Pin eingeben und dann wurde das erfolgreich signiert. Man sieht hier ist jetzt eine weitere Datei entstanden, eine P7S-Datei. Wenn ich eben ausgewählt hätte, dass der Vertrag mitten das Dokument hier eingebettet hätte werden sollen, dann wäre das eine P7M-Datei. Genau. Diese beiden Dateitypen sind definiert in RC 5652. Es handelt sich da also um PKI Signaturen in PKCS7-Format. Und aus diesem RC kann man auch entnehmen, in welcher Dateistruktur diese Daten in dieser Signaturdatei abgelegt werden. Das ist das ASN1. Das heißt, wenn man das anguckt, mit einem ASN1-Viewer, dann sieht man irgendwie, es ist eine Baumstruktur. Man sieht, es gibt zu jedem Objekt, beziehungsweise Element in dieser Baumstruktur eine Längenangabe. Dann enthält diese Datei allerlei Objekt-Aidentifier und darauf folgen dann eben die Daten, die zu diesen Objekt-Aidentifying gehören. Ich würde jetzt nicht so genau darauf eingehen. Auf jeden Fall, die Datei ist klar definiert und klar strukturiert. Nach den Zertifikaten, die jetzt eben eingebettet wurden, also hier sieht man jetzt das Unterzeichner-Zertifikat, wobei man im Prinzip nichts sieht, weil alles zugeklappt ist. Es ist im Prinzip so ein Standard X 509 Zertifikat mit ein paar Erweiterungen, zum Beispiel muss ja in jedem Zertifikat auftauchen, dass es für qualifiziert elektronische Signaturen geeignet ist. Das schreibt ja die EU vor. Also gibt es eine Erweiterung, die dann eben genau diese Information im Inhalt hat. Und dann gibt es eben die weiteren Zertifikate vom Aussteller und vom Aussteller des Ausstellers. Und am Ende gibt es dann die Signed Attributes in der Datei. Die Signed Attributes enthalten jetzt eben diesen Haschwert von der Datei, die wir signieren wollten und mit Zeit in einem bestimmten Format, die man genau, also die Signed Attributes enthalten im Prinzip genau die Daten, die signiert werden sollen. Und zusätzlich zu diesen beiden Daten gibt es noch weitere Daten, nämlich einmal gibt es noch einen Bezug auf das Unterzeichnheitszertifikat. Also es ist ein Signed Certificate für uns Freien. Das nimmt dann eben mittels Haschwert Bezug auf das bereits vorher in der Datei vorhandene Unterzeichnheitszertifikat. Also man bildet dann einfach ein Haschwert hier drüber und das ist dann genau dieser Haschwert. Und zusätzlich gibt es dann in diesen Signed Attributes auch noch eine Information, wer der Aussteller dieses Zertifikats ursprünglich war und vor allem, wo es Rückrufinformationen zu Zertifikaten von diesem Aussteller gibt. Über dieses Signed Certificate, am Ende der Datei taucht dann auf jeden Fall das Signed Schafvalue auf, also der letzten in das verschlüsselte Haschwert, der an die Karte geschickt wurde. Noch einmal zusammengefasst, die Signatur der Datei enthält die Zertifikate, dann irgendwelche Algorithmen identifiert, die Arschfunktionen, die Daten letztendlich gehesht wurden. Dann dieses Signed Attributes field, das wieder Bezug auf die Zertifikate nimmt und nochmal den Haschwert der Datei enthält und Design in Time. Und am Ende gibt es dann eben den Signed Schafvalue, der eben die eigentliche Signatur darstellt und besonders oder auch nicht besonders, ist jetzt eben das für einzelne Abschnitte die Längenangaben in der Datei mit drinstehen, damit man eben von vorneherein weiß, wie lang ist die Datei, wie lang ist der Abschnitt, den ich jetzt gerade lesen will. Ja. Jetzt kann man sich natürlich fragen, jetzt wird das so eine Datei erzeugt, wo kommen denn die Daten daher? Man weiß jetzt, es ist irgendwie ein USB-Gerät, also kann man irgendwie mal gucken auf die USB-Leitung, zum Beispiel mit USB Snoop oder Sniff USB, der hat nach und nach den Vortrag mit dem Reverse-Engineering für USB-Geräte gehört, der kennt noch andere Tools. Ich habe es jetzt mit den beiden gemacht, die zeigen dann baldweise die Übertragung in Rotdaten an. Das ist schön, weil man schon mal zugerufen auf die Daten hat, aber leider auch irgendwie nicht so schön, weil man eben nicht so wirklich erkennen kann, was dann da jetzt wirklich übermittelt wird. Bei diesem Paket ist es noch recht einfach, weil das ist einfach dieses Set-Up-Packet. Da wird am Anfang einfach erstmal mitgeteilt, was ist das für ein Gerät, was da gerade dranhängt? Wie kann man mit dem kommunizieren? Also hier sieht man, es gibt irgendwie drei Endpunkte und die haben verschiedene Adressen natürlich. Hier ist eins, da ist die 83, da ist die 82, genau. Es gibt verschiedene Größen für die Transfer-Salz, für die maximale Packer-Salz, die man damit übermitteln kann. Und es gibt verschiedene Kommunikationstypen. Burg heißt dabei einfach, das ist ein normaler Datentransfer und Interrupt ist für wichtige Daten, die das Gerät ein Mitteilen will. Und dieser Interrupt Endpoint, der hat auch eine Zeit, die man nicht unterschreiten darf, beim Abfragen. Also den darf man jetzt hier nur alle 16 Millisekunden einmal abfragen. Die Burg Endpoints, die sind halt einfach zur Kommunikation freigem. Also wer sich daran noch nichts vorstellen kann, im Vergleich der vielleicht ein bisschen hinkt, ist es mit TCP-Ports, die sind ja auch einfach irgendwie Objekte, mit denen man irgendwie kommunizieren kann, die Daten durchstecken kann und genauso öfter hier auch. Wenn man dann aber weiterguckt, dann werden diese Pakete leider nicht mehr so genau aufgeschlüsselt, sondern es kommen halt recht kryptische Befehle einfach. Man sieht nichts mehr. Jetzt gibt es natürlich die Möglichkeit, einfach sofort eine Stunde zu gucken und sich das Ganze ziemlich einfach zu machen und einfach nachzulesen, was wird übermittelt. Aber selbst wenn man das noch nicht tut, kann man einfach mal weitergucken und entdeckt dann so was. Und so was, also sehr lange und sehr kurze Pakete, wobei die nur in sehr begrenzter Stückzahl auftauchen. Also da kann man sich schon fragen, was machen die da genau? Genau, das ist dann, man sieht, was man sieht. Und wenn man das Ganze dann noch mit zeitlichen Schritten im Signaturvorgaben verbindet, dann sieht man, dass diese kurzen Blöcke genau dann auftreten, wenn die Pinne eingegeben wird. Also die übertragen da, hey, es wurde eine Taste gedrückt, hat man ja auch eben gesehen, dass es dann eben auf dem Bildschirm dieser beiden durchlief. Und wenn man das Ganze nochmal wiederholt unter gleichen Ausgangsbedingungen, dann sieht man, dass sich da nur sehr wenige Unterschiede ergeben, und zwar in genau 3 Request-Böcken. Und zwar der erste ist der Haarschfett, der an das Gerät gesendet wird. Und zwei sind einfach die Antwort darauf, und da steht das Signatur-Value dran. Das heißt, man kann jetzt im Prinzip schon sagen, dass, ah, Moment, man kann es jetzt noch weiter auseinandernehmen, die Kommunikationsarten, die da eben verwendet, werden, sind USB, hatte ich ja schon gesagt. Dann gibt es anhand der gerede Klasse, die dieser Kartenleser darstellt, die Möglichkeit, da ein Standard zu gucken, und da kriegt man eben raus, es handelt sich um CCID-Gerät, und diese CCID-Messages, die starten jede Nachricht, erst mal mit einem 10-Biteheader aus, das hat die Nutzdatenfang irgendwie ab bite 11 an. Und dann gibt es eben noch diese Kommandose, die aus dem ISO Standard kommen, die den Transfer komplett auseinandernehmen, dann stellt dann fest diese großen Datenblöcke, die man eben gesehen hat, die treten immer dann auf, nachdem eine Datei ausgewählt wurde, also mit dem Select-Befilm, der tauchte irgendwo auf, dann kommt eben eine FileID, dann kommt das Kommandose, dass man diese Datei auch lesen will, und gibt zusätzlich noch ein Abwoman, die Datei lesen will, anschließend kommt dann eben so ein fetter Datenblock, und dann kommt von mir aus nochmal das ReadBinary-Commando, eben, bis man die Datei freuständig gelesen hat. Dann stellt man jetzt diese Datenblöcke, die man da übermittelt hat, vergleicht mit der Signaturdatei, dann stellt man eben zusätzlich noch fest, dass die Datenblöcke die Zertifikate sind, die in der Signaturdatei vorhanden sind. Außerdem konnte man eben sehen, dass da die Pin-Eingabe übertragen wird, und die Pin-Eingabe wird eingeleitet mit dem Verify-Kommando, und nachdem die Pin dann fertig eingegeben wurde, das heißt, also der User hat auf dem Chipkartenterminal die bestätigen Klasse gedrückt, berechnet die Karte halt, ob die Pin auch richtig war und antwortet dann entsprechend, und wenn die Pin dann richtig war, dann darf der PC auch die Computed Liter Signature Anweisung schicken, inklusiv eines Hash-Werts, der dann signiert werden soll, und daher sieht man im Transfer dann eben leider, dass der Hash-Wert, den man da signiert, unleicht dem Hash-Wert ist, der eigentlich von der Datei kommt. Und das liegt daran, dass die eben in der Signaturdatei haben Sie ja diese Sign-Attributes zusammengebaut, und da sind ja nützlich Informationen drin, die für die Signature interessant sind, nämlich diese Informationen, wo kriege ich denn Informationen, ob Zertifikate zurückgerufen wurden, oder von wem überhaupt das Zertifikat stammt, und wer hat es überhaupt unterzeichnet? Das muss ja alles irgendwie mit eingehashed werden, und deshalb bildet man dann eben noch mal ein Dateihash über diese Signature Attributes, also über diesen Abschnitt, das ist die Signaturdatei, und den schickt man an die Karte zum Signieren. Das heißt also, der eigentliche Dateihash geht nur indirekt, mit in den eigentlichen Hash-Wert ein, der da signiert wird. Als Fazit kann man jetzt feststellen, die gesamte Datenverbindung ist umgesichert. Man sieht, wie die Zertifikate übertragen werden, man sieht, wie die Pin-Eingabe übertragen wird, wenn man auch nicht sieht, welche Pin-Nummer eingegeben wird, man sieht doch, dass Pin-Nummer eingegeben werden. Es ist es möglich, die Nutzdaten zu erkennen, also ich kann nicht nur sehen, dass der Zertifikat übertragen werden, sondern ich kann auch sehen, welche Zertifikat übertragen werden. Man kann sehen, dass die Elemente, die da übertragen werden, in genau der Reihenfolge übertragen werden, in der sie auch nachher in den Signaturdatei auftauchen, und deshalb kann man eben diese Nutzdaten ganz einfach abgreifen und mit schreiben. Jetzt war meine Aufgabe, eine Angriff auf das Signaturgerät, das bedeutet, also ich möchte eine Signatur fälschen, und das heißt wieder, ich möchte diese Signaturdatei fälschen. Und wir hatten schon gesehen, in der Signaturdatei sind nur recht wenige Variablen, und es ist deshalb fast nahezu linear möglich, die Datei aufzubauen. Wenn man nochmal guckt, wie die Datei genau aussieht, man sieht hier irgendwie die Versionskennung, also in welche, wie die Datei genau aufgebaut ist, irgendwelche Identifier, dazu muss ich noch sagen, die Karte, die die deutsche Post hier ausliefert, unterstützt genau drei Algorithmen. SHA-1, RIPE MD-160 und SHA-256. Und die Bundesnetzagentur hat SHA-1 und RIPE MD-160 als zu unsicher eingestuft. Das heißt, die Karte kann nur noch einen Algorithmus, der für qualifizierte elektronische Signaturen erlaubt ist. Das heißt also, das sind im Prinzip alles Konstanten hier. Und wenn man von vorneherein sagt, man will eine Signatur fälschen, wo keine Daten mit drinstehen, dann ist auch das hier leer. Das heißt, das ist im staatischer Datei Kopf. Das Zertifikat, bzw. die Zertifikat T, die kann man einfach beim Transfer mit schreiben. Genauso wie die Auszuler-Daten und die Seriennummer, weil die stehen in den Zertifikaten mit drin. Algorithm Identifier ist dann wieder eine Konstante, weil man ja weiß, mit welchem Algorithmus man die Daten letztendlich es herrscht. Den Message digest muss man logischerweise irgendwie in die Datei selbst mit einbringen, genauso wie die Signing Time. Es nützt ja nichts, was mir der PC schickt, sondern ich will meine eigene Datei signieren. Das Signing Certificate V2, das wird jetzt leider im Klartext überhaupt nicht übertragen. Das muss ich mir also aus dem alten Signing Certificate komplett selbst zusammenbauen. Ist aber kein Problem, weil ich habe das Signing Certificate ja komplett mitgelesen. Ich kann also den Herdschweiz selbst bilden. Ich kann mir die Auszuler-Daten da komplett selbst rausholen. Ich kann auch die Seriennummer rausholen. Kann ich also auch ohne weiteren Aufwand einfach hintereinander wegschreiben. Einziges Problem bisher ist also, die Länge der Certificate, weil am Anfang der Datei steht leider eine Längenangabe, aber wenn ich die Certificate mitgelesen habe, kann ich mir die Länge berechnen und am Ende vorne eintragen. Den Signature Value kriege ich übrigens auch wieder komplett im Klartext aus dem Transfer. Wenn man das Ganze dann irgendwie umsetzen will, baut man sich eine Save Machine. Die Schratze erst in der Teikopf hatten wir ja gesehen. Der ist einfach statisch. Wartet dann darauf, dass die Certificate auf der Karte ausgewählt werden. Wenn in so eine Certificate ausgewählt wurde und auch übertragen werden soll, dann können wir es einfach mitschreiben. Wenn es dann fertig ist, warten wir auf das nächste Certificat. Und am Ende, wenn wir alle Certificate haben, können wir uns die Designer Infos bzw. die Designer Activity zusammenbauen. Dann wieder darüber den Herdsch bilden und müssen dann nur darauf warten, dass der User irgendwann mal seine PIN eingibt und die PIN dann auch bestätigt wird von der Karte. Und wenn der User dann seinen Herdsch fährt, an die Karte steckt, dann tauscht man einfach den Herdschwert aus, der vom User signiert werden soll. Die Karte signiert meinen Herdsch bzw. den Herdschers Angreifers. Schickt als Antwort den Signature-Welt für meinen Herdsch. Wir können ihn mitschreiben und sind dann im Prinzip fertig. Jetzt kann man sich natürlich fragen, wie komme ich an die Daten ran? Wenn man sich diese Kette irgendwie anguckt, der User hat ein PC, der will jetzt irgendwas machen, benutzt dafür irgendwelche Software. Dann kann ich natürlich sowieso machen, was ich will. Ich könnte mir einen eigenen Treiber schreiben, der einfach nicht die Daten an die Karte steckt, die der User schicken will, sondern ich schreibe meinen eigenen Treiber, der halt meine Daten an die Karte steckt. Das Problem dabei ist aber, man braucht Zugriff auf den Operating-System-Kontext. Wenn er jetzt etwas, was sich in den Passwort eingestellt hat oder die Karte verschlüsselt ist oder es halt einfach nicht so einfach ist, daran zu kommen, ist das halt problematisch. Man kann dann gerne irgendwo anders eingreifen. Und das Smartpad-Termine selbst ist jetzt wieder mit irgendwelchen Siegeln versiegelt. Also wenn man das öffnet, dann ist das recht auffällig. Also bleibt als eine Ein-Siegestelle eben, man sieht nur noch dieser Datalink. Und wir hatten ja schon gesehen, der ist unverschlüsselt. Brauchen wir uns also nur noch irgendwas überlegen, was man dazwischen schalten kann, was dann eben genau diese Datenmanipulation vornimmt. Hier sieht man jetzt nochmal ein Szenario, wo der Angegriffene im Prinzip schon mit unserem Gerät ausgestattet wurde. Man sieht irgendwie, man möchte da wieder bei Funk drauf zugreifen. Also angenommen, die Putzfrau hat das jetzt am Wochenende mal reingesteckt und jetzt putzfrauen zu nahe treten zu wollen. Dann möchte ich nicht, dass die nächste Woche wieder dahin gehen muss und die Sicht natur abzuholen, sondern ich möchte da irgendwie von draußen auf zugreifen können. Also das ist das naheliegendste, was die Daten und ich kann da bei Funk drauf zugreifen. Das wäre ja schon mal irgendwie eine tolle Feature Liste. Das Usag, das ist also das Gerät, was hier dazwischen geschaltet wurde. Das steht erstmal, also wir hatten ja vorhin gesehen, der Gesetzgeber nennt diese Chipkartenterminus und Chipkartenlösung Secure Signature Diva... Secure Signature Creation Device. Auf Deutsch also, sichere Signature Erstellungseinheit für sicheres Signature Erstellungsgerät und wir hatten aber gesehen, die Verbindung ist ungesichert. Also könnte man da irgendwie ein Gerät bauen, was die Signature abgreift. Und dieses Gerät zum Eingriff in die USB-Verbindung muss jetzt eben genau zwei Verbindungen erzeugen, nämlich einmal muss es sich gegenüber dem PC als Device ausgeben, nämlich als Kartenleser und gegenüber dem Kartenleser muss es halt so tun, dass es ein PC ist und das auch berechtigt ist, den Daten zu schicken. Jetzt gibt es natürlich zum Glück Mikro-Controller, die irgendwie USB-Verbindungen aufbauen können. Das heißt man braucht nicht irgendwie sich darum kümmern, wie kriege ich jetzt die Bits auf die Leitung. Aber leider können diese Mikro-Controller eben nur eine USB-Verbindung zur Zeit aufbauen. Also braucht man zwei Controller und dann eben eine Kommunikation zwischen den Controllern und die Funkanbindung, die musste auch irgendwie mit rein. Wenn man das dann umsetzt, kriegt man so einen schönen Schaltplan, der auf den Verbindungsleitungen und ein Funkmodul und irgendwas um halt die Spannung irgendwie zu regulieren, aber das ist auch nicht so wichtig. Wenn man es dann umsetzt, sieht so aus. Also eine recht kompakte Größe kann man schon gut mit einem Schreibtisch verstecken. Sind jetzt natürlich noch irgendwelche Dip-Geräuse. Wenn man da irgendwie S&D-Geräuse nimmt, kriegt man das bestimmt noch deutlich kompakt dahin. Das kann ich aber nicht mehr löten und ich habe auch keine Möglichkeit gehabt, mir eine Platine zu etzen. Die wird natürlich auch irgendwie programmiert werden. Also jeder Controller kriegt natürlich sein eigenes Programm und zuerst fangen wir mal auf der linken Seite an, also der, der quasi mit dem PC redet. Der möchte am Anfang erstmal seine Daten vom USB-Bus abholen, weil es ist immer so, bei USB wird jede Verbindung oder jeder Transfer vom Host initialisiert. Das heißt also, wir sind ja hier in diesem Fall ein Device. Wir müssen also darauf warten, dass der Host irgendwie eine Kommunikation anfängt. Fangen dann also an, warten darauf, dass der irgendwie Daten von dem Endpunkt abholt. Wenn diese Daten dann da sind, dann können wir die einfach mit der SPI-Verbindung an den zweiten Controller bemitteln. Also SPI ist diese Verbindung, die eingesetzt wird, um zwischen den beiden Kontrollern zu kommunizieren. Und nachdem dieser Zustand eben fertig ist, gibt es mehrere Möglichkeiten. Entweder wir haben wieder Datenempfangen, die halt vom Krankenlister zurückkommen, die müssen wir dann irgendwie an die entsprechenden Endpunkte weiterleiten. Oder wir haben keine Datenempfangen und müssen dann wieder bei Endpunkt 1 nachfragen, ob der noch Daten für uns hat. Und jetzt hatten wir vorhin gesehen, in dem initialen USB-Paket, was da über die Leitung läuft, gibt es irgendwie eine Angabe, dass diese Endpunkte in eine bestimmte Waffergröße haben. Und wir hatten jetzt gesehen, diese Waffergröße war 40, 0x40, also 64 bytes. Und wir hatten gesehen, dass diese Datenpakete über die Leitung kommen, deutlich größer sind teilweise. Das heißt also, wenn da irgendwie 64 bytes überschritten werden, dann wird der hier damit allein nicht mehr fertig, sondern er muss dann in mehreren Schritten die Daten abholen. Das macht er eben hier. Und nachdem er halt komplett fertig ist, schickt das weiter. Also das sieht man hier nur, wo kriegen wir Daten her und wohin schicken wir die. Und dieser State Automate liefert eben genau das. Und was ganz ähnlich ist, gibt es eben im zweiten Controller. Der kriegt seine initialen Daten aus dem SPI-Status, also vom anderen Controller. Leitet das dann eben weiter an den Gratenleser bzw. holt vom Gratenleser dann Daten ab, wenn er irgendwie aus dem SPI keine Daten bekommt. Und checkt die dann auch wieder zum anderen Controller. Und zusätzlich liefert er eben noch eine weitere Sache. Und zwar, er stellt ja unsere Signaturdatei. Also wir hatten ja vorhin gesehen, dieser FI-Qualification-Prozess, wie müssen wir die Datei aufbauen. Jetzt kommt eben noch dazu die Funkverbindung. Und zwar können wir uns am Anfang, wenn wir das Gratidaten in einem unbekannten Zustand befinden. Es ist entweder gar keine, es ist entweder gar keine Daten verfügbar, was wir signieren wollen. Dann können wir darauf warten, dass wir irgendwie was empfangen. Verstetigen das dann und versuchen dann, diese Datei zu erzeugen. Oder wir haben schon Daten empfangen, konnten die aber noch nicht signieren. Dann können wir direkt damit anfangen, diesen Prozess zu durchlaufen. Oder wir haben schon fertig signierte Daten in unserem Speicher liegen. Das heißt, wir warten nur darauf, dass der Angreifer, die auch abholt mit seinem Gerät. Das heißt, wir erwarten wieder darauf, dass eine Verbindung geöffnet wird. Wir Daten senden können, die Daten bestätigt werden und dann irgendwie unsere Daten aus unserem Gerät in das andere Gerät kriegen. Der Angreifer braucht natürlich auch irgendwie ein Gerät. Nämlich das, was die Daten letzten Endes zum USAP übermittelt bzw. sie da abholt. Idealerweise, weil wir ja auf Dateien zugreifen wollen, nämlich diese Signaturdatei, die da gestellt wird, verhalten wir uns also wie ein USB-Stick. Hier ist übrigens ein Fehler in der Vorjahr. Er sendet nämlich nicht da an zum USB-Stick, sondern dieser USB-Stick sendet da an zum USAP. Und nachdem das USAP irgendwie fertig ist, empfängt das ASIC eben die erzeugte Signatur. Das ASIC steht einfach für Angreifer-Signatur-Erstellungsgerät, also analog zu dem USAC als ASIC. Schaltplan ist ganz ähnlich. Mikrocontroller, wieder eine Reihe Datenverbindungen, die jetzt aber nicht mit einem anderen Controller verbunden sind, sondern eben mit dem Funkmodul. Es sah dann so aus, als Programmierung, Zustandsautomat ergibt sich wieder irgendwie so was. Also man hat am Anfang keine Daten in dem Gerät erfügt, aber verhält sich also als Master-Deutsch-Device. Wenn jetzt in einem bestimmten Sektor dieses Master-Deutsch-Devices ein bestimmtes Fleck gesetzt wird, dann wissen wir, wir haben jetzt irgendwie Daten, die wir verschicken wollen. Also fangen wir an, die zu übermitteln, warten darauf, dass das bestätigt wird. Und wenn wir dann diesen Zustand vollständig verlassen haben, dann können wir darauf warten, dass die Daten vom USAP zurückgeschickt werden, die da signiert wurden, und können das wiederum bestätigen. Und wenn das vollständig immer wieder durchlaufen wurde, dann sind wir wieder in einem Zustand, wo wir alles, was wir mit Funk-Zuzonen haben, erledigt haben und können dann wieder zuhofft auf die Daten gewähren. Also in diesem Zustand verhalten wir uns immer wie ein Master-Deutsch-Device. Ein Angriff kann einfach so ablaufen, das USAP wird platziert. Also zum Beispiel die Reinigungskraft oder vielleicht hat man irgendwie selbst ein Termin mit dem Anwalt, den man da Signatoren unterschieben will. Verhält sich dann solange transparent, wie einfach keine Daten zum Signieren vorliegen, damit es halt nicht entdeckt wird. Wartet aber gleichzeitig irgendwie auf eine Funkverbindung. Dann muss der Angreifer irgendwie sein Aset konfigurieren, den Reichweite bringen und die Daten übertragen. Und wenn die Daten dann vollständig übertragen wurden, dann muss das USAP natürlich seine Aufgabe erliegen und irgendwie die ganzen Zertifikate mitschneiden und dann endlich den Signature-Value da mit auslesen und mitschreiben. Es wartet also auf einen definierten Zustand, weil also man sieht im Transfer, im Initialen Signaturvogang werden immer alle Zertifikate übermittelt, aber wenn schon irgendwelche Signaturfragen gelaufen sind, dann wird das nicht alles nochmal wiederholt, sondern es wird eben dann die Kommunikation auf ein nötiges Beschränk. Natürlich könnte man jetzt irgendwie anfragen, selbst stellen an den Kartenleser und sagen, hier gibt mir mal dieses Zertifikat, aber man sieht dann eben hier an dem Kartenleser, ist so eine kleine LED, die blinkt dann fröhlich vor sich hin. Also wenn jetzt unter dem Gerät irgendein Tisch, unter dem Tisch irgendein Gerät versteckt ist, was da eigentlich ständig Kommandos an die Karte steckt, dann sieht man eben auf dem Tisch, hier blinkt LED. Was soll das? Es fällt also auf. Man wartet also auf einen definierten Zustand, wo eben alle Zertifikate übermittelt werden. Schreibt die Stück für Stück mit. Dann, wenn ein Signaturfragen gedurchgeführt wurde, wäre es natürlich einfach die Möglichkeit, man schickt einfach den Hasht, der da von der Karte zurückkommt bzw. die Signatur, die von der Karte zurückkommt, einfach weiter an den Anmender-PC. Das Problem dabei ist, der Anmender kriegt dann eine Fehlermeldung angezeigt, so was wie es an Datenkommunikationsfehler aufgetreten. Es wäre möglich, dass die Leitung manipuliert wurde oder so. Und das ist ja genau das, was wir gemacht haben und darauf freuen wir den User ja irgendwie nicht hinweisen. Also zeigt man dem User halt irgendwie eine kryptische Fehlermeldung. Also ich habe mich jetzt hier für den Fall zu entschieden. Man könnte auch sowas machen wie invalid response from the card received oder einfach Null. Also sehr nicht zu angene Fehlermeldung. Es ist auf jeden Fall in den User dazu verleiten, irgendwie seine Pin noch mal einzugeben oder den Telefon einfach abzubrechen. Was auch immer er macht, in dem Moment, in dem er die Meldung angezeigt bekommen hat, ist, dass wir unsere Signature schon erhalten, beziehungsweise erzeugt und haben im Prinzip unsere Sache im Gast. Und es kann jetzt egal sein, wie es weiter läuft. Hauptsache, das Usag fällt sich wieder transparent und wird eben nicht entdeckt. Nachdem die Signature-Dateiteilung eben erzeugt wurde, braucht das Usag plus noch darauf warten, dass das ASAC wieder in Reichweite kommt, um eben die Daten zu verschicken. Verschickt die Daten und dann war es das auch schon. Jetzt würde ich eigentlich eine Live-Demo machen. Mir wurde eben davon abgeraten, weil man angeblich wenig davon sehen wird. Ich probiere es einfach mal. Ich hoffe, dass es klappt. Also ich habe jetzt hier mein Usag. Ich habe hier mein Usag. Da stecke ich jetzt zwischen Karten, Leser und PC. Man sieht jetzt, gleich fängt die LED-Offentier an zu blitzen. Ich weiß nicht, sieht man davon was? Gut. Das verhält sich jetzt erstmal transparent. Also wenn ich jetzt hier eine Signaturfahrung durchführe, na, das ist ganz blöd. Ich lösche mal die alte Signatur. Okay, ich muss natürlich die Anwendung auch neu starten, weil die kriegt das immer nicht mit, wenn man den Karten-Leser abzieht. Also wie gesagt, ich hatte ja im Vortrag stehen, hier sieht man, ich muss mich abziehen, das Karten-Leser ist unten neu start der Anwendungssoftware. Okay, also der hat jetzt die Karten-Daten wieder abgerufen. Man sieht genau so weiter laufen wie vorher. Man muss wieder seine Pinne eingeben und der Teil wurde erfolgreich signiert. Also man sieht, es verhält sich transparent. Ich ziehe es jetzt wieder ab, dann konfiguriere ich einfach mal meinen ASec. Ich habe hier also ein weiteres Gerät. Das ist jetzt im ersten Moment einfach mal ein USB-Stick, mit selbe Grenzen Speicherplatz, irgendwie 8 Kilometer oder so. Und ich habe schon eine Datei vorbereitet, nämlich MyFile.Text, die ich jetzt einfach mal signieren will. Und dafür brauche ich Konfigurationsdateien. Zum einen eine Datei, die man sieht, einfach dieses Fleck enthält, den Herrschwert, den wir signieren wollen und die Zeit. Und eine weitere Datei, die einfach so eine Platzalter-Datei ist, also die besteht jetzt nur aus 0xFF. Die ist einfach nur dazu da, damit ich irgendwie ein Speicherbereich in dem ASec schon mal reservieren kann, wo dann nachher die eigentliche Signatur hingeschrieben werden soll. Sobald ich jetzt hier die Signy.Text hier rüber ziehe, sollte das ASec den Zustand wechseln und dann die Datenvertragung hier zum Usag starten lassen, dass man sie natürlich wieder anstecken. Also man sieht das Blitz fröhlich vor sich hin. Ich möchte die Datei natürlich ersetzen. Man sieht jetzt, oder ich hoffe man hat gesehen, dass es kurzzeitig etwas anders geblitzt hat und die Daten eben übertragen wurden. Das ASec ist jetzt eben auch nicht mehr verfügbar beziehungsweise er kriegt hier einfach die Meldung nicht vernünftig weg. Also das ASec hat den Zustand gewechselt. Es ist als USB-Mass-Touch, die weiß nicht mehr verfügbar. Ich kann es jetzt im Prinzip abziehen. Wenn ich jetzt hier meinen Vertrag wieder signieren will, es läuft wieder alles genauso ab wie vorher und leider ist die Pin falsch. Wenn ich jetzt das ASec wieder in Reichweite bringen, dann erkennt das natürlich erst mal nicht, weil es noch in einem anderen Zustand ist und das Usag möchte auch gerade die Verhobenverbindung nicht aufbauen, oder? Ich weiß nicht, was da jetzt gerade schief geht, aber das Usag möchte die Verhobenverbindung nicht aufbauen, das fängt nicht an zu blitzen. Ich lasse es erst mal laufen und komme dann zu meinem Fazit. Man sieht auf jeden Fall die Verbindung, die da abgelaufen ist, die ist nicht gesichert. Also das wird im Klartext übertragen. Man sieht, dass der Gesetzgeber das ja auch nicht gefordert hat. Das heißt also, die Verbindung ist einfach zurecht ungesichert. Man hätte jetzt sehen sollen, man hat es leider nicht gesehen, weil das Usag sich nicht bequem, hier die Funkverbindung aufzubauen. Da es qualifizierte elektronische Sichtungen sich fälschen lassen, wenn man diese Verbindung halt angreift. Fazit, sichert eurer Verbindung. Jetzt könnte man natürlich argumentieren, es gibt noch andere Anwendungen, die verschlüsselte Kommunikationsverbindungen einsetzen, zum Beispiel in den E-Person und später auch mal eine Signaturverbindung haben sollen. Aber solange das vom Gesetzgeber eben nicht gefordert ist, ist dieses Produkt, man sieht so schwach wie sein schwächtes Glied, wenn es hier eben ein Produkt gibt, bei dem man Verbindungen fälschen kann, Signaturen fälschen kann, dann kann man die eben fälschen und das ist eben blöd. Außerdem sind eventuell weitere Attacke möglich, und zwar haben wir ja gesehen, es wird bei jedem Tastendruck irgendwas übermittelt und deshalb könnte man eventuell da noch eine Timing-Attacke draufsetzen, um zu gucken, kann man die Pinder ausspänen, also kriegt man über das Timing zwischen zwei Tastendrucken, so wie das beim SSH eben auch gelaufen ist, heraus, was der User eingegeben hat. Weiß ich nicht, könnte man aber mal versuchen. Das wär's. Ja, falls jetzt Fragen sind bemerkbar machen, dann kommt ein Mikrofon zu euch. Nehmen wir den in der 5.6.3. Zwei Fragen. Zum einen, ist das nur mit einem Gerätetyp möglich oder gibt es Geräte, die optional eine Verschlüsselung haben? Also wie gesagt, es geht hier um eine spezielle Implementierung. Es gibt auch Geräte, zum Beispiel irgendwelche Anwälte, haben sogar die Anforderung, dass sie Lese einsetzen müssen, die Verbindungen verschlüsseln. Also es gibt Geräte, die die Verbindung verschlüsseln. Ob es Geräte gibt, die die Verbindung teilweise verschlüsseln, weiß ich nicht. Antwort ist das die Frage? Okay, aber das war ein Gerät, was für die qualifizierte elektronische Signatur zugelassen war. Richtig, danke. Also die Post hält sich da komplett an die Anforderung des Gesetzes. Man kann damit qualifizierte elektronische Signaturen erstellen. Man kann damit mit den vorbestellten Geräten auch Signaturen abgreifen bzw. fälschen. Ja, weitere Fragen? Wir haben eine Frage aus dem IC, ein Moment mal. Ja, also eine Frage ist, wie hoch ist die Verzögerungsset durch diese USB-USB-Kopplung? Richtig, also die Controller, die da mit dieser SPI-Verbindung kommunizieren, da ist die SPI-Verbindung der Flaschenhals. Also ich habe die SPI-Verbindung jetzt irgendwie bei einem Megahertz getaktet. Das führt bei diesem Platinenlayout schon teilweise zu Datenfehlern. Man könnte die SPI-Verbindung auch deutlich höher takten, sodass es keine Verzögerung mehr wäre, aber eben nicht mit diesem Platinenlayout. Das heißt, man müsste eventuell irgendwie eine Platine erätzen, um Verzögerungszeiten, die dann tatsächlich zu erreichen, die tatsächlich nicht mehr bemerkt werden könnten. Weitere Fragen aus dem Publikum. Hier vorne ist eine. Bein drückende Arbeit. Sprechst du denn selber USB mit dem Kartenreader oder schleifst du nur die Pakete vom PC durch? Ich schleife im Prinzip, also zwei Allei, also den Großteil der Pakete schleif ich einfach durch, um mit dem Kartenreader, also an, ja, nein, doch. Du hast zwei Controller, nicht? Ja, genau, ich habe zwei Controller, also zwei. Und die sind unabhängig voneinander? Die sind unabhängig voneinander, richtig. Und der Großteil der Pakete schleif ich tatsächlich durch. Lediglich, wenn ich den PC gesagt habe, dass die PIN falsch ist, dann versucht der PC irgendwie, mit dieser PIN-Falschmeldung umzugehen und schickt dann irgendwie ein Kartenreader. Das kann ich natürlich überhaupt nicht gebrauchen, deshalb graf ich das ab und schickt dem PC einfach eine Fake Antwort. Und gleichzeitig, nachdem der PC informiert hat, wurde, dass die PIN falsch war, schickt dann natürlich nicht mehr das Create Signature Kommando, sondern das muss ich dann eben selbst schicken. Und der Teil der Kommunikation ist eben auch gefährlich. Alles klar. Wir haben noch eine Frage aus dem IEC. Ja, was würde passieren, wenn jetzt die Reihenfolge der Pakete auf der USB-Stelle in irgendeiner Form vertauscht werden würden? Die Reihenfolge, also das ist richtig, die Implementierung, wie sie jetzt ist, ist ziemlich dicht an dem Transfer, wie er eben in die Saalmendung stattfindet. Aber man sieht eben trotzdem die Select File und Get Binary Befehle. Das heißt also, solange man diese Befehle irgendwie aus dem Transfer noch wieder rausholen kann, gibt es auch eine Möglichkeit, die Zertifikate abzugreifen. Und das Computer-Tutorial Signature Kommando ist eben auch im Klartext einfach. Das heißt, auch da gäbe es kein Problem. Okay, sind weitere Fragen? Was würde passieren, wenn du quasi dem Rechner sagen würdest, anstelle des Kartenlesers, ja, nee, PIN war schon okay, obwohl sie nicht okay war, könnte, würde dann der Prozess vorgesetzt werden oder ist, sprich ja, der Kartenleser quasi den Zustand? Also, die Karten sind jetzt so ausgelegt, dass sie nur eine Signatur pro Zeit machen können, also eine Signatur pro PIN-Eingabe. Die Post bietet aber zusätzlich noch so gesamte Stapelverarbeitungskarten an, wo man dann eben einmal die PIN-Eingibt und dann 100 Dateien signieren kann. Da hätte man das als Angreifer bei einer ungesicherten Verbindung natürlich noch viel einfacher. Bei dieser Karte geht es aber nicht, also die Datei, der Karten, die Karte würde nach einmaliger PIN-Eingabe auch nur eine einzige Signatur erzeugen. Und wenn ich dann eben die vom PC weiterleite, dann erzeugt eben der PC seine Signatur und ich kann meinen nicht einsetzen. Und wenn ich meine hinschickt, dann muss eben der PC leiden. Weitere Fragen, da hinten ist noch eine. Dann nehmen wir die aus dem IEC erstmal inzwischen. Ja, hier ist noch die Frage aufgekommen, ob auch der E-Person über diese Art Sturmelis ohne Eignis-Tastenfeld angreifbar wäre. Also wie gesagt, mit dem E-Person ist die Verbindung zur Auspeiserb gesichert. Also irgendwie verschlüsselt. Ich weiß nicht genau, wie es da läuft, aber ich weiß, dass sie gesichert ist. Der E-Person hat selbst aber im Moment eben noch keine Signatur-Funktionalität. Also um die Frage zu beantworten, nein, man könnte es nicht auf die gleiche Weise angreifen, weil eben die Verbindung gesichert ist. Okay, jetzt die Frage aus dem Publikum. Mit Klasse 3-Karten-Lesegeräten müsste das nicht funktionieren, oder weil die ja sollten ja anzeigen, was signiert wird, bevor man es dann signiert. Eigentlich sollte das so sein, richtig. Aus dem Transfer hier jetzt ging noch hervor, dass zuerst die PIN, also es wird gesagt, ich möchte jetzt irgendwie eine sicherheitskritische Aktion durchführen, dann wird die PIN abgefragt und dann wird der Herr Schwett an die Karte geschickt. Also, wenn das bei Karte Klasse 3-Lesegeräten genauso abläuft, dann würde es bedeuten, dass das jetzt gar nichts anzeigt. Man soll die PIN eingeben und dann kommt der Herr Schwett und der User kann nichts mehr machen. Aber ich habe sie eben nicht untersucht, wenn es so wäre, wäre es traurig. Weitere Fragen, sieht nicht so aus, denn danke ich nochmal, Alexander, für den interessanten Einblick.