 So, Willkommen in Klark, wir hören jetzt dann gleich Eric Sesterhen, der hat 15 Jahre als Konsultin gearbeitet im Bereich Penetration Testing und Source Code Consulting, Entwicklungskonsulting. Er hat schon einen Defcon Vortrag gehalten und jetzt zum Abschluss hier am CTC. Der Vortrag ist in Sowjet-Russia-Smartcard-Hack-SU, also in Sowjet-Rusland-Hack-D-Smartcard-Dicht. Eine Runde Applaus, bitte. Herzlichen Dank. So, also ich wurde ja schon vorgestellt, ich bin Eric. Ich bin schon lange in CCC Wiesbaden oder vorher meins dabei. Ich komme seit einer Weile an den Kongress. Ich muss zugeben, das ist das erste Mal, dass ich ja so Angst habe hier auf der Bühne. Es ist wunderschön, dass der Kongress immer größer gewachsen ist. Es ist so lässig, jedes Jahr hier zu sein. Also herzlichen Dank an alle Helfer. Also Smartcards waren schon immer ein Thema am Kongress, schon vor 19 C3, aber davor gab es keine Aufnahmen. Und ich meine, die Alten will man vielleicht auch nicht unbedingt anschauen. Also es kommt immer wieder vor dieses Thema. Also wenn ihr durstig seid nach mehr Information, dann schaut euch mal die alten Aufzeichnungen an. Einige Talks sind sehr gut da. Wenn man sich die Geschichte anschaut von Smartcard-Hacking, dann die meisten Attacken haben die Smartcard im Mittelpunkt und dieser Talk, da geht es ein bisschen um was anderes. Also die Probleme, die ich hier vorstelle, wurden gefixt. Also ich habe die bei den Projekten gemeldet und geholfen, diese Sicherheitslücken zu schließen. Ich habe vor allem Open Source Projekte angeschaut. Weil ich meine, wenn ihr ein probiertes Hersteller seid und Geld macht mit diesen Dingen, dann solltet ihr auch jemand bezahlen, diese Software sicher zu machen. Da gibt es eine Ausnahme allerdings. Und ein Freund von mir muss halt einen bestimmten Smartcard-Treiber verwenden und da habe ich schnell angeschaut. Aber da in ein paar Abenden habe ich keine ernsthaften Sicherheitsprobleme gelesen, aber ein paar Abstürze gefunden und ja, darüber spreche ich auch noch ein bisschen. Also was sind Smartcards und wo werden die benutzt? Also ihr kennt sie von EC-Karten, Kreditkarten, die Jüngern vielleicht SIM-Karten, in den Mobiltelefonen, manchmal für die Eltern-Semester hier, auch Bezahlkarten für nicht Münstelefonen, sondern Kartentelefonen. Eine andere Anwendung ist natürlich Authentifizierung. Also als zwei Faktor, zum Beispiel, wenn ihr bei Linux euch einloggt, dann kann das sein, dass es mit Passwort und Smartcard funktioniert. Das Passwort kann man klauen, indem man über die Schulter guckt bei der Angabe. Aber wenn man einen zweiten Faktor hat, zum Beispiel die Smartcard, dann muss man den auch irgendwie abgreifen und das ist viel schwieriger. Also die Smartcard gilt da eigentlich als sicherer. Also ich habe jetzt vor allem dieses Login-Szenario angeschaut. Interessant ist, dass das als Root läuft. Also wenn man da eigentlich Bugs findet, dann kann man sich als Root anmelden und nicht bloß als ein normaler User, obwohl man natürlich für normalen User vielleicht bloß das Passwort hat, nicht für Root. Also das ist natürlich noch ein psychologisches Element. Also die Entwickler für die Smartcard haben das Gefühl, dass sie Smartcard vertrauenswürdig ist und die trauen der Smartcard auch, wenn sie die Antwortpasen, die die Smartcard gibt und da machten sie dann vielleicht Fehler, die Autoren von Netzwerktreibern nicht machen würden. Also schauen wir uns mal den Smartcard-Stack an. Was gibt es da für Schichten? Was für Teile gibt es da? In der Kommunikation, wir werden jetzt durch diese, alle diese Schichten durchgehen und ich sage euch zu ihr, da war es dazu. Also grundsätzlich hat man ein manipulationssicheres Gerät. Also dieses Smartcard werden so hergestellt, dass die Schlüssel, die da drauf gespeichert werden, da drin bleiben. Also in der Vergangenheit gab es da Angriffe und die, da ging es um Glitching oder die Smartcard irgendwie dazu zu bringen, diese Schlüssel auszugeben. Also man hat hier ein paar Pins, die den Chip einschalten und da haben wir ein Ausgabechips und diese, für diese Kommunikation hat man bestimmt das Protokoll, dass sie Smartcard und das Lesegerät verstehen. Das Protokoll besteht aus APDUs. Also im Prinzip kleine Pakete oder Befehle, die man als Smartcard schickt. Das erste Byte ist ein Class Byte, das spezifiziert, ob das Commander aus dem Standard ist oder ein Hersteller spezifischer Befehl. Dann gibt das Instruktionsbyte, da drin steht, jetzt kommt dieses Kommando. Zum Beispiel, wenn man Text 20 hat, dann ist das ein Verifizierungsbefehl. Also das heißt, man schickt den Pin der Smartcard und sagt ihr, okay, das ist hier mein Pin, bitte, entsperre dich. Dann haben wir zwei Parameter, bei denen man zusätzliche Informationen übergeben kann und weitere Daten halt an die Karte schicken, noch weiter hinten. Also die Smartcard beantwortet dann diese Anfrage mit einem Blobdaten und am Ende der Daten kommen zwei Bytes. Also da gibt es zum Beispiel Executor Successfully, also erfolgreich ausgeführt, das ist 9000 oder dass ein bestimmter Fehler passiert ist. Eine interessante Antwort hier ist 6.1. Da heißt, ich habe dir was geschickt, aber ich habe noch mehr Bytes, die ich dir schicken möchte. Also ja, da haben wir noch bestimmte Fehler, die kodiert sind, bei denen man mehr Informationen hat oder nicht. Also zum Beispiel hier, du konntest dich nicht authentisieren und du hast noch einen Versuch übrig oder so. Dann haben wir eine Abstraktions-Ebene oben drüber, diese heißt PCSC. Das ist eine API, um diese APDUs an die Smartcard zu schicken. Also es gibt da einige weitere Funktionen, um irgendwie über den Reader was rauszufinden, also ob eine Karte drinsteckt oder eine Nachricht zu erhalten, wenn die Karte entfernt werden. Aber das Wichtigste für mich war diese Transmit Funktion, diese Übermittlungsfunktion. Also hier hat man einen Buffer, das sind die Daten und dann hat man einen anderen Buffer, wo dann die Draten von der Smartcard-Antwort drin sind. Und das Schöne an dieser Abstraktionsschicht ist, das ist das Gleiche auf Windows und Linux. Oben drauf hat man noch eine andere Abstraktionsschicht. Da wird nicht über Karten gesprochen, sondern über kryptografische Tokens. Also man kann da eine Smartcard brauchen oder einen Soft-Token. Und das hier ist auch standardisiert, diese Schnittstelle. Also ein Browser braucht die, OpenSSL braucht diese Schnittstelle. Und das noch mal eine Abstraktionsschicht, die ziemlich generisch ist. Wenn man einen Treiber schreibt für Smartcards, wollt ihr normalerweise dieses Interface implementieren und das PCSC Interface drunter, braucht man nur mit der Karte zu kommunizieren. Hier das Smartcard, die man einsteckt, schickt eine bestimmte Reihe von Befehlen und reagiert auf Resets und da ist bestimmte Information encodiert, wie man mit der Smartcard sich unterhält und auch welche Bytes man schicken muss. Also man sieht da auch irgendwie zu welchem Wender die Smartcard gehört und der Treiber braucht diese Information, um herauszufinden, ob der Treiber mit dieser Smartcard umgehen kann oder nicht. Also wie sieht dieser Login-Prozess aus? Also normalerweise hat man PAM, also man hat irgendwie eine grafische Oberfläche oder Shell-Login-User, auch dahinter PAM, um die Autorisierung zu handhaben. Die PAM-Wertake versucht erstmal eine Liste von Certificaten auf das Smartcard zu kriegen. Wenn ein Certificat passt für einen bestimmten User, dann auf der sich, wenn da sich rausstellt, dass der sich einloggen darf, dann wird überprüft, ob das Certificat wirklich noch gültig ist. Wenn das Certificat gültig ist und der User auch zum Certificat passt und der User sich einloggen darf auf diesem System überhaupt, dann generiert der Computer einen Nonce, also eine Zahl zu einmaligen Verwendung, also einfach ein zufälliger BitString. Und die Smartcard muss für diese Nonce eine Signatur generieren. Und wenn die Smartcard das tun kann, wissen wir, dass die Smartcard den Private Key enthält, um dann zu antworten und dann auf der User sich einloggen. Beginn wir mit einem proprietären Treiber, die spanische elektronische Idee, die entspricht der EU-Direktive. Sie hat auch ein Chip. Mein Freund muss das benutzen. Ich weiß nicht, was der rechtliche Hintergrund ist, aber jedenfalls ist das so. Er hat sich sehr darüber beklagt. Und darum habe ich rasch darauf geschaut. Das wurde herausgegeben für Linux vor 10 Jahren. Ist eine Bibliothek, die nicht besonders gesichert ist? Das ist 10 Jahre alte Technologie. Wir haben zwei Open Source Bibliotheken, die genutzt werden, eine Krypto. Ich weiß nicht, ob sie wirklich notwendig sind. In jedem Fall haben sie es nie abgedeutet. Und dann gibt es die ASN1c. Die Größe zeigt, dass da sehr viel Text da ist. Ich weiß nicht genau, was passiert. Auf jeden Fall hat es kein Kopie-Reit drauf, für alle die Leute, die da Open Source benutzen. Ich habe damit rumgespielt. Ich habe ein paar einfache Sachen geschrieben. Manchmal verlangte der Treiber eine Antwort. Ich habe mehr Daten für Sie. Ich frage eine weitere 0-Bytes von mir. Du kannst dann Ping-Pong spielen. Es kann sein, dass es irgendwann einmal die Nile of Service gibt, wenn man dann die Zahl überschritten hat. In Security will man natürlich nicht den Nile of Service machen. Man will ja, dass da irgendwas gemacht wird. Ich habe jetzt 255 Beide reingespiesen. Ich habe das in eine Schleife gemacht, immer wieder die 255 Beide reingefütet. An einem bestimmten Punkt gab es einen Crash. Da wurde der Buffer überschritten. Das war nichts, was man irgendwie ausnützen kann. Wenn du antwortest, dass das funktioniert und du sagst, das ist keine Daten, sondern nur ein Code, dann ist alles okay. Dann kannst du ihn auch crashen lassen. Es ist auch nicht interessant, aber man sieht, was alles schiefgehen kann. Ich habe andere Sachen gefunden, die nicht so laufen wie es sein sollten. Nichts schien wirklich ausnützbar. Ich wollte auch nicht, dass der Herrscher das mitbekommt. Auch bei proprietary Software gibt es ähnliche Issus. Das sind die verschiedenen Treiber, die ich angeschaut habe. Einer hat 9000 Burks und der hat offenbar einige Probleme. Das Projekt Exist hat 20 Jahre, so ein gewisser Code ist natürlich ein bisschen veraltet. Für OpenSC danke ich Frank Morgner. Der hat das koordiniert, um das alles fixen zu lassen. Man kann sich vorstellen, das ist nicht ein einziger, der das alles entwickelt hat. Da waren 20, 30 Leute. Jeder hat unterschiedliche Karten. Und wenn man einen neuen Release rauslässt, ist es einiges zu tun. Apple war interessant, dass ich Ihnen den Back mitgeteilt habe. Sie haben das ganz still und leise gepatched. Offenbar wird das gegenwärtig gar nicht benutzt. In den heutigen Maschinen, die Sie verkaufen. Es ist etwas aus der Vergangenheit. Ich musste Sie dann fragen und bitten, das zu korrigieren. Ich bekam keine Antwort. Sie sehen, ihr seht hier ein Loop, dass es noch nicht mehr gibt. So, der nimmt die Daten entgegen und bringt sie in den Buffer. Der Entwickler, der das geschrieben hat, hat viel Vertrauen in die Smart-Karte gesteckt. Da habe ich vorhin schon gesprochen. Die Karte kann einfach sagen, ich kann immer noch mehr Daten brauchen und irgendwann fließt es über. Ein interessanter Problem im OpenSC ist der Cryptoflex. Sie haben einen 2048-Bytes-Speicher. Sie nehmen die Select-File Function, um Meta-Informationen über das File einzuholen. Eine ist die Größe der Datei. Sie nehmen die Größe, die dem Buffer entspricht. Wenn die Karte 5000 Kilobytes hat, dann wird der Buffer überlaufen. Ich habe hier eine kleine Demonstration. Das Tool ist ein Helfer-Tool, das z.B. auf die Karte liste. Das Tool ist auch, um die verschiedenen Zeichen aus der Karte auszulesen. Wenn man es für Rieden will, dann ist es nicht ein Szenario, das man ausnützen kann, aber schön zu wissen. Ein anderer Hersteller ist Ubico. Die kleinen Devices verkauft, die auch Smart Cards haben, z.B. vom USB-Stick. Sie haben diese Funktion auf Ihrem Gerät. Sie kopieren dann die Daten, die Sie rausgeholt haben, auf dem Speicher. Sie prüfen, ob die Daten, die empfangen wurden, größer sind, als der Speicher war. Dann gibt es eine Fehlermeldung, aber Sie machen einfach weiter, und dann bringt es natürlich nichts. Das ist natürlich einfach zu korrigieren, aber das sind die Dinge, die eben so passieren. Ich hoffe, das zweite Proof-of-Konzept, das kann man meistens aufrechnen. Das ist jetzt für das klassische Linux-Login. Wir kümmern uns nicht um den Username. Sobald die Smart Cards angelesen werden, kopieren Sie die Daten. Nicht der Burger S. Nach einer gewissen Zeit kommt die Fehlermeldung ausgelöst. Der Output-Buffer ist zu klein, und es wird weiter reingeschrieben. Also ja, das lässige ist, hier am Ende gibt es dann halt eine Codexecution, und ich bin als Route eingeloggt. Also wie kann man jetzt das in der Praxis ausnutzen, dieser Bug? Einfachsten wäre es natürlich, wenn man die Custom Hardware brauchen könnte, um mit einem Smart-Card-Reader zu kommunizieren. Da müsste man irgendwie Träte haben, die aus dem Reader kommen. Das wäre natürlich gut beim Linux-Login oder vielleicht bei einem Geldautomaten geht das nicht so oder Access-Control-Systems. Wenn man das Basic-Card verwendet, dann muss man ihn Basic schreiben, aber man kann das ganze Smart-Card-Zeug machen, das man machen will. Das Wichtigste ist, dass man das ATR Vollkast machen kann. Also, Answer to Reset. Das heißt, man kann es so hin basteln, dass jeder Treiber deine Karte akzeptiert. Also auf einer tiefen Ebene definiert man hier die Bytes vom ATR. In diesem Fall hier ist das für den OpenSC-Treiber. Und dann deklariert man die Funktionen, die die ATD braucht. Also hat man ein Großbuch starten bei Class Bytes und ein Instruktion Bytes von A4. Und wie die Funktion heißt. Und da kann man noch Parameter übergeben und dann hat man hier noch Generatoren. So, das hier ist das MySelect-File, die Funktion. Da kann ich angeben, welche Data-Treiber auswählen will und dann in diesem Fall hier meine statische Antwort auswählen. Also dieser Code ist ziemlich dämlich für dieses Kommando, aber ich meine, ich wollte einfach mal schauen, wie das funktioniert und wie ich den Treiber halt angreifen kann. So, wie findet man Box im Smartcard-Treiber? Also man kann natürlich manuell den Source-Code auditieren. Das habe ich auch gemacht. Und eine andere Lösung ist halt, das mit Fuzzing zu machen. Also ich meine, das ist im Prinzip, man schickt da ganz viele Bullshit-Daten an den Treiber und versucht rauszufinden, was dann passiert. Das Problem ist, viele Fuzzing-Tools sind halt so gebaut, dass sie auf Basis von Files funktionieren. Also die sind nicht so gebaut, dass man Pakete schicken kann und nicht Antwort erwartet. Also man hat da die Herausforderung sozusagen den File-Input vom Fuzzer umwandeln in etwas, das wie Protokoll-Daten funktioniert. Das Schöne ist halt hier mit diesem S-Card-Transmit-Rapper, das sagt einem, wie viele Daten das Empfang der Ende erhalten will, also wie viel da gelesen werden soll, wie viele Bytes. Also die Idee war halt hier dann eben, diesem Buffer immer bis zum Ende zu füllen mit Daten aus einer Datei. Und weil es nicht Netzwerk orientiert ist, muss man hier irgendwie sich nicht um Pauling kümmern oder so. Also man kann einfach den Buffer füllen. Das sieht dann jetzt für OpenSC so aus. Also ich habe hier einen virtuellen Laser gebaut und dieser hat dann eine Schnittstelle zum Fuzzer. Also ich habe da AFL verwendet, American Fuzzy-Lob und dann habe ich mir dann Code Coverage angeschaut, um zu sehen welches Input-File da irgendwie interessant ist und welches nicht. Also das war also der größte Teil von meinem Projekt eigentlich. Ich habe es auch versucht, also ich meine, das habe ich gemacht. Ich habe eine Bibliotheke geschrieben, die man auf Windows oder Linux preloaden kann und so, dass die SmartCard mit diesem neuen Code intragiert, anstatt mit dem echten Reader. Und damit kann man halt auch praktisch beliebige SmartCard-Treiber fassen. Aber das ist noch nicht genug damit. Letztes Jahr, Tavis hat Teile von Windows Defender, also von Windows Antiviren-Lösung auf Linux portiert und der Code, den er fassen wollte, er wollte einen sehr, sehr kleinen Umgebung laufen lassen. Also bei Fuzzing ist es halt immer schön, wenn man sehr viele Interaktionen in kurzer Zeit machen kann, weil je schneller das Fuzzing geht für ein bestimmter Code, desto wahrscheinlicher ist es, dass man Bugs findet, weil man halt mehr zufällige Daten ausprobieren kann. Also ich habe diese Library genug geprügelt, dass ich Windows SmartCard-Treiber auf Linux laden konnte, um sie zu testen. Also gibt es bestimmte Ausnahmen, wenn man dort nicht Treiber habt, dann geht das nicht, weil es halt von sehr vielen zusätzlichen Bibliotheken abhängt. Aber alles, das halt einfach direkt in C geschrieben ist, sollte ja nicht funktionieren. Ja, also diese Fuzzer habe ich veröffentlicht, die könnt ihr hier herunterladen. Also wenn da was nicht geht, dann schreibt mir einfach eine E-Mail. Also so sieht AFL aus, wenn man es laufen lässt. Ich habe es insgesamt etwa 28 Tage laufen gelassen und konnte da ziemlich viele Bugs aus OpenSC rauswerfen. Aber wenn wir jetzt die Coverage Reports anschauen, ist die Coverage nur 30%. Also ich meine, dass es nicht so schlimm, wenn man jetzt dran denkt, dass die Antworten müssen hat für viele verschiedene Requests richtig sein. Also am Anfang versucht der SmartCard-Treiber zu prüfen, dass die Karte ja wirklich existiert und dass man damit interagieren kann und versucht, gewisse Files aufzumachen und ließ gewisse Files. Und ich meine, also man braucht irgendwie 10 Befehle bevor irgendwie was Spannendes passiert. Also zum Beispiel die Auflistung von Zertifikaten oder so. Also ich meine, ich war ziemlich erstaunt, dass ich überhaupt so weit gekommen ist. Und ja, natürlich hat man hier am unteren Ende einige Files, die 0% Coverage haben, also Funktionen, die ich gar nie angefangen habe, dass man hier Treiber, die halt standermäßig ausgeschalten sind und am anderen Ende der Tabelle für gewisse Treiber war die Coat Coverage aber ziemlich hoch. Ich war schon überrascht, dass mit so einem einfachen Aufbau das so gut funktioniert hat. Also ich meine, ich habe einfach irgendwie 2 Beispiel-Files reingeworfen und damit konnte ich sehr viele verschiedene Funktionen auslösen durchs Fuzzing. Also es ist ja nicht nur die Treiber, die interessant sind in diesem Setup, sondern auch so die oberen Schichten, also in PAM-Module zum Beispiel. Eines davon, das man brauchen kann für Smartcard Lobby ist dieses PAM-PKCS-11. Und der Prozess sieht hier sehr ähnlich aus, aber mit einem wichtigen Unterschied, das ist da, wo die Nonce erzeugt wird. Also wenn man die Nonce erzeugt, braucht man gute Zufallsdaten, weil wenn man die Nonce erraten kann, wenn der Angreifer die Nonce erraten kann, weil wenn diese Nonce später nochmal verwendet wird, kann eine Attacke einen Replayangriff machen. Also man braucht halt da eben viel Entropie und es hat so ein kleines Hilfsmodul, das die Entropie generiert. Also sie haben im Prinzip diese Smartcard danach gefragt, zufällige Daten zu erstellen, und dann wird die Smartcard gefragt, eine Signatur zu erstellen. Also wenn der Angreifen Computer kontrolliert, dann kann er halt die Nonce und die Signatur für die Nonce erhalten und kann halt dann damit ein Replayangriff machen. Also das ist dann auch ein interessanter Fehler, bei der man wieder die Psychologie des Entwicklers sieht, dass der Karte halt traut. Ja, natürlich gibt es auch irgendwie Probleme, wenn man solche Triberexploits schreiben will. Also die Daten, die an die Karte geschickt werden, sind ziemlich klein. Und wenn man irgendwie Information League basteln will, ist das schwer zu machen, weil man nicht wirklich Interaktion hat. Also man hat keine Tastatur oder kein Bildschirm bei der Smartcard, aber wenn man natürlich da irgendwie Träte anlöten oder so, dann gibt es da irgendwie Firmware, bei der man nicht bloß man in der Mittel machen kann, sondern dass man hinschicken kann, was man will. Also der Vorteil ist halt, dass man da nicht notwendig wie es Code Ausführung machen muss, sondern einfach, naja, man will einfach bloß ein paar Bits im Speicher flippen, die dann angeben, dass der user jetzt eingeloggt ist. Also was ich davon gelernt habe, ist, dass ich immer dacht, dass Smartcards sind was Gutes für zwei Faktor-Attentisierung, aber ich habe mir nie wirklich gedacht, wie das die Angriffsfläche vergrößert, wenn man als Smartcard-Attentisierung einführt. Das ist so ähnlich wie Antivirus, also es hilft bei der Sicherheit, aber wenn die Antivironsoftware einen Fehler hat, ist das halt dann auch ziemlich schlimm. Also wenn ihr OpenSC braucht, da gibt es eine Konfigurationsoption, die man brauchen kann, um bestimmte Treiber black oder white zu listen. Also das heißt, dann kann man so machen, dass bloß die Treiber laufen, die man wirklich braucht. Also das reduzieren natürlich die Größe der Angriffsfläche. Und die Ubico-Leute, die haben halt 9 Treiber in Pfeifen geschrieben und da hat man natürlich diese Speicherkorruptionsfehler dann einfach nicht mehr. Also wenn ihr die Möglichkeit habt, das so zu machen, dann ja, bitte. Also danke euch. Wenn ihr jetzt noch Fragen habt, dann ... ... und ja, ich benutze nicht Twitter, sondern nur die Social Network. Es trinkt mich zu using, es ist LinkedIn. So, sorry für das. Und wir haben fünf Mikrofonen für Fragen, und wir haben so ungefähr fünf Minuten. So, wir haben jetzt noch Zeit für Fragen. Bitte stellt euch beide Mikrofonen hin. Und die Exzits sind die zwei, die nach links sind. Es gibt eine Frage aus der Mikrofonnummer 1. So, ich habe eine Frage, die etwas komisch ist vielleicht, aber hast du so etwas versucht mit RFID-Karten? Also bei vielen Smartcard-Readers, zum Beispiel bei Türen, muss man eine Karte hinhalten und kann man da irgendwie den Türöffner fassen. Das Protokoll ist das Gleiche bei Türen, aber ich habe nicht damit herumgespielt. Wer den Raum verlässt, bitte ganz ruhig. Hast du schon versucht, das mit einem Microcontroller zu machen, also anstatt der Basic-Card? Vielleicht gibt es da irgendwie ein gescheites Framework, das man brauchen könnte. Das ist das, was man möchte tun. Das ist das. Ich habe das versucht. Sie haben eine zweite Version herausgegeben. Ich würde auch in diese Richtung gehen. Ein Freund möchte auch ein PCB massgeschneidert machen. Es gibt ganz viele Optionen. Komm doch nachher zu mir, ich spreche dann darüber. Also dein Tag ging jetzt vor allem um bösartige Karten, die den Angriff starten und den Leser kompromittieren. Gibt es auch eine Möglichkeit, einen RSA-Key oder so aus der Karte rauszuholen, oder ist das zu sicher? Das ist das. Das ist das. Das ist das, was ich angeschaut habe. Ich bin kein Hardware-Mensch. Der Toc von Carsten Null. An einem der Camps war gut. Ihr habt das gesehen, in der Däpholien. Und eben, ja. Ich bin ein Software-Guy, also Entschuldigung. Ist das PKCS-Protokoll und PCR-Protokoll? Ja, das ist das. Ist das PKCS-Protokoll und PCSC-Software-Sack zu kompliziert? Und könnte man das mit etwas einfacherem ersetzen? Problem ist nicht die Software, die Komplexität. Wir haben die realen Daten, die der Driver schickt. Manchmal sind es Herstellerangaben. An diesem Allsturm passiert einiges, wo es Probleme gibt. Danke für den Talk. Eine Frage. Du hast gezeigt, dass diese Sicherheitslücken im Treiber, das heisst doch, dass jeder PC eine Smartcard-Authentisierung erlaubt, hat dann ein Problem mit dieser Root-Lock-Inlücke. Die Treiber sind nicht installiert standartmäßig. Und bei Windows manchmal. Weil die Hersteller haben die zur Verfügung. Ich weiß nicht genau, warum sie das tun. Es ist hier ein Business-Modell. Normalerweise muss man das speziell aktivieren am PC. Sicher auf Linux, und bei den anderen kann ich es nicht genau sagen. Zu diesen RFID-Karten nochmal. Im Android-Telefon kann man ja einen NFC-Controller brauchen, um einen NFC-Tag zu simulieren. Man müsste doch diese NFC-Tag-Emulator in einem Android-Telefon brauchen, um das Fuzzing für NFC-Tags zu machen. Wäre das ein guter Ansatz? Ich habe das Fuzzing nicht auf der Basik-Karte gemacht. Ich habe sie nur gemacht, um sie auszunützen. Ich wollte ganz viele Iterationen machen, um möglichst viel auszulösen. Man kann das tun, was hier vorschlagt. Es gibt auch kontaktlose Karten, die verkauft werden. Ich habe das nicht. Man kann die Fernwehre auf dem Mobile-Telefon angreifen, um es zu entsperren. Ich weiß es nicht. So, gerne nochmal einen Applaus für Eric.