APDU Commands um Daten von einer SmartCard abzufragen

  • APDU Commands um Daten von einer SmartCard abzufragen

    Hallo,

    ich versuche im Moment ein Case zum Auslesen von EC Karten in meine App zu integrieren. Das Case kann sowohl per Magnetstreifen, was auch schon vollständig funktioniert, als auch per SmartCard Reader auslesen.
    Für das Case gibt es ein eigenes SDK, woraus ich aber nicht so wirklich schlau werde. Das Auslesen des Chips ist im Moment mein Problem. Mit der iOS App soll keinerlei Zahlung getätigt werden, es soll nur die Bankverbindung ausgelesen werden, also Kontonummer und Bankleitzahl bzw. die PrimaryAccountNumber.

    So nun zu dem was ich bisher versucht habe.
    Ich habe eine Methode die über ein Delegate aufgerufen wird wenn ich eine EC Karte in das Case eingesteckt habe.
    In dieser Methode kann ich mir dann, durch den Aufruf einer Einschalt Funktion des Readers, eine AnswerToRespond abholen.

    Quellcode

    1. NSData *theData = [[NSData alloc] init];
    2. theData = [dtdev scCardPowerOn:slot error:&theError];

    Das klappt und die ATR weißt auch genau auf die Herkunft der Karte hin.

    Das Problem ist nun der nächste Schritt, der Aufruf über das Application Protocol Data Unit (APDU). Dort gibt es diverse Commands mit der man an die Informationen des Chips herankommen soll, Problem dabei, das hat bei mir die Verwirrung auf 100% gesteigert. Ich muss dazu sagen, ich bin noch relativ neu in der iOS Welt und bin mit der Aufgabe doch dezent überfordert X/ .

    Mit dieser Funktion theAPDUData = [dtdev scCAPDU:SLOT_MAIN apdu:commandAPDU error:&theError]; soll nun darauf zugegriffen werden, allerdings beinhaltet die Funktion eben nur Werte wenn das Command richtig übergeben wurde und ist ansonsten nil, was bei mir immer der Fall ist.

    Ich habe mich ein wenig im Internet umgesehen und dazu einiges Ausprobiert, allerdings hat das nicht funktioniert.
    Die Versuche von denen ich mir am meisten was erhofft hatte:


    Quellcode

    1. unsigned char getResponseCommand[] = {0x00, 0xC0, 0x00, 0x00, 0x12};
    2. NSData *commandAPDU = [AJDHex byteArrayFromHexString:@"00 C0 00 00 12"];
    Beim Zweiten Versuch habe ich auf eine Klasse und eine Funktion zurück gegriffen die in einem anderen SDK aufgerufen wird um den String in Bytes umzuwandeln.


    Wie schon gesagt, ich bin total verwirrt und habe bis jetzt nicht den Aufbau von APDU´s verstanden und demnach auch noch keine Möglichkeit gefunden einen Aufruf in Objective-C zu machen.

    Meine Fragen wären nun also, ob sich eventuell jemand damit auskennt oder schon mal damit gearbeitet hat und in der Lage wäre ein wenig Licht ins Dunkle rund um das Thema APDU zu bringen, damit ich verstehe wie solche APDU Commands in Objective-C aufgebaut sein müssen.

    Verwirrte Grüße
  • Schau' Dir mal die PC/SC-Spezifikation an. Die gibt's kostenlos zum runterladen. Musst halt googlen. Da findest Du alles Grundlegende. Ansonsten wenn es um konkrete Kommandos (bzw. APDUs nach ISO 7816-4 ) für EC-Karten geht, wirst Du wahrscheinlich um die SECCOS-Spezifikation (gibt's zum Kaufen beim Bankverlag) nicht drum rumkommen.

    Generell ist so eine APDU einfach eine Folge von Bytes mit einer Länge von mindestens 4 Byte. Insofern ist Dein Versuch oben den HexString in ein NSData-Objekt zu wandeln schon korrekt (vorausgesetzt die Methode "byteArrayFromHexString:" macht das, was der Name andeutet). Jetzt musst Du nur noch die korrekten APDUS senden

    ciao

    gandhi
  • Moin.

    Chronisch schrieb:

    ich versuche im Moment ein Case zum Auslesen von EC Karten in meine App zu integrieren.
    Was meinst Du eigentlich mit "Case"? Was soll das sein?

    Chronisch schrieb:

    ...es gibt ein eigenes SDK, woraus ich aber nicht so wirklich schlau werde.
    Es könnte ggfs. mal hilfreich sein zu wissen, welches SDK Du benutzt.
    Und auch welches Terminal.

    Chronisch schrieb:

    Das Auslesen des Chips ist im Moment mein Problem.
    Welcher Kartentyp? DDH? RDH? Welche Versionen? etc.

    Chronisch schrieb:

    ... Das klappt und die ATR weißt auch genau auf die Herkunft der Karte hin.
    Der ATR übergibt die Kommunikationsparameter für das Terminal. Zum Beispiel welches Protokoll die Karte und Terminal erwartet T0= oder T=1. Taktung, etc. Mit der "Herkunft" der Karte hat das nur wenig zu tun.

    P.S.: Hier wird das schön erklärt.

    Chronisch schrieb:

    Das Problem ist nun der nächste Schritt, der Aufruf über das Application Protocol Data Unit (APDU). Dort gibt es diverse Commands mit der man an die Informationen des Chips herankommen soll, Problem dabei, das hat bei mir die Verwirrung auf 100% gesteigert. Ich muss dazu sagen, ich bin noch relativ neu in der iOS Welt und bin mit der Aufgabe doch dezent überfordert X/ .
    Die APDUs hängt von der verwendeten Karte (dem ICC), der dortigen Applikation und deren Betriebssystem ab. Mit iOS hat das wiederum nichts zu tun.

    Wie gandhi bereits schrieb, es gibt ein standardisiertes Protokoll definiert in ISO 7816-4, aber viele ICCs der Karten wie bspw. die mit SECCOS, TCOS, Java & Co. haben z.T. eigene abweichende Command Sets. Die Spezifikationen dafür kann man käuflich erwerben.

    Chronisch schrieb:

    Mit dieser Funktion theAPDUData = [dtdev scCAPDU:SLOT_MAIN apdu:commandAPDU error:&theError]; soll nun darauf zugegriffen werden, allerdings beinhaltet die Funktion eben nur Werte wenn das Command richtig übergeben wurde und ist ansonsten nil, was bei mir immer der Fall ist.
    Natürlich. Wenn man sich das ansieht, kann man erwarten, dass der Fehler wird via theError zurück kommt.

    Chronisch schrieb:

    Ich habe mich ein wenig im Internet umgesehen und dazu einiges Ausprobiert, allerdings hat das nicht funktioniert.
    Das ist ja auch ein kompliziertes Thema. Und das hat mit iOS Entwicklung nahezu gar nichts zu tun.

    Da kannst Du Dir mal die Grundlagen aneignen. Introduction to Smart Cards

    Chronisch schrieb:

    Wie schon gesagt, ich bin total verwirrt und habe bis jetzt nicht den Aufbau von APDU´s verstanden
    Meine Fragen wären nun also, ob sich eventuell jemand damit auskennt oder schon mal damit gearbeitet hat und in der Lage wäre ein wenig Licht ins Dunkle rund um das Thema APDU zu bringen, damit ich verstehe wie solche APDU Commands in Objective-C aufgebaut sein müssen.
    Wie bereits geschrieben, ist von der verwendeten Karte, der dortigen Applikation und deren Betriebssystem abhängig. Die APDU bleiben gleich, egal welche Sprache (C, Java, Python, Pascal, ) man verwendet. Das hat weiterhin nichts mit Objective-C zu tun.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von NSObject ()

  • gandhi schrieb:

    NSObject schrieb:

    Was meinst Du eigentlich mit "Case"? Was soll das sein?
    Vielleicht "Use case"?
    Ist ein Bluepad-500 [Blockierte Grafik: http://www.datecs.bg/assets/BluePad-500/1%20BluePad-500.jpg]

    @NSObject Danke für die vielen Erklärungen, das Auslesen einer Smart Card wurde erstmal stillgelegt. Wir warten damit nun erstmal ab, da wir noch mit dem Hersteller in Kontakt stehen und das ganze meine Kompetenzen doch etwas übersteigt.
  • Moin.

    Chronisch schrieb:

    @NSObject Danke für die vielen Erklärungen, das Auslesen einer Smart Card wurde erstmal stillgelegt. Wir warten damit nun erstmal ab, da wir noch mit dem Hersteller in Kontakt stehen und das ganze meine Kompetenzen doch etwas übersteigt.
    Ja, ich denke Du hast eine völlig falsche Vorstellung, von dem was Du tun wolltest. Darauf deutet jedenfalls das meiste in deinem Eingangsposting hin.

    EC-Karten sind keine Speicherkarten (wie z.B. die alte KVK), sondern Smartcards. Das sind kleine kryptographisch spezialisierte Rechner. Die haben einen Prozessor, verschiedene Speicher, ein Betriebssystem. Die haben Anwendungen, Protokolle, etc. Und das alles ist sehr Low Level. - Eine kurze Zusammenfassung über die Prozessorkarten findest Du in der Wikipedia.

    Ich hatte noch mal in einen alten Unterlagen gewühlt, die Spezifikation für die EC-Karten solltest Du dort bekommen: EMV Co
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von NSObject ()