Clever Geek Handbook

Wie wir eine Bankkarte von einem iPhone in einen Schlüsselbund geladen haben



Jedes Jahr zeigen immer mehr Unternehmen Interesse an Projekten im Zusammenhang mit dem Internet der Dinge ( IoT ). 



In diesem Artikel werde ich über die von uns erstellte IoT-Plattform sprechen, wie Bankkarten in tragbare Geräte geladen werden, die Funktionen des Core NFC iOS-Frameworks untersucht werden und ein mögliches Betrugsschema bei Verwendung von Smartphones mit NFC.



Der Artikel kann für Produktmanager, Technologen, iOS-Entwickler, QS-Ingenieure, die sich mit mobilen Zahlungen beschäftigen, sowie für alle, die sich für Fintech-Technologie interessieren, nützlich sein, um ihren Horizont zu erweitern.



Hallo Habr!



Ich heiße maxim. Ich mache seit 2005 industrielle Entwicklung. Ich arbeite seit 2013 in Wallet und unterstütze seit 2015 das Unternehmen bei der Entwicklung neuer Fintech-Dienstleistungen als Abteilungsleiter.



Bei Wallet hat unser Team viele innovative Produkte auf den Markt gebracht. Dies ist eine der weltweit ersten vollständig virtuellen Bankkarten in einem Smartphone mit der Möglichkeit des kontaktlosen Bezahlens (ein Jahr vor dem Start von Apple Pay in Russland und lange vor dem Start von Apple Card) sowie die erste Transportkarte und die erste Fan-Karte sowie die erste Campus-Karte in einem Smartphone. ...



Im vergangenen Jahr haben wir zusammen mit Mastercard den Wallet Pay-Service eingeführtIst der einzige Dienst auf der Welt, der im Gegensatz zu seinen Kollegen unabhängig vom Smartphone-Hersteller oder Betriebssystem funktioniert. Pay Wallet funktioniert beispielsweise auf Huawei- Smartphones , auf denen Google-Dienste fehlen.



Danksagung



Kolya Ashanin , die mich zum Schreiben des Artikels motivierte und mir bei der Vorbereitung der Veröffentlichung half.



Sasha Pryimak, die unter meiner Aufsicht die im Artikel beschriebenen Untersuchungen durchgeführt hat.



Vielen Dank auch für Ihre Teilnahme und Unterstützung:

Katya Turkina, Anton Davydov, Lesha Ershov, Dasha Alekseenko.



IoT-Plattform



Momentan arbeiten mein Team und ich an der Einführung einer Internet of Things-Plattform, die die vorhandenen Erfahrungen mit der Nutzung des Bezahldienstes ergänzen und erweitern und Zahlungsmethoden (und andere Identifikationsdienste) in den Dingen implementieren kann, die wir normalerweise bei uns tragen - den sogenannten tragbaren Geräten. 



Das Internet der Dinge ist ein Konzept vertrauter physischer Objekte, die mit Technologien ausgestattet sind, um mit der externen Umgebung oder miteinander zu interagieren. 



In diesem Konzept werden bekannte Anwendungsfälle für Dinge durch Automatisierung neu erstellt.



Ein Beispiel für tragbare Geräte sind intelligente Uhren, Fitnessarmbänder, Ringe und Schlüsselanhänger.



Wenn früher eine Person wegen Schönheit oder Symbolik einen Ring trug, dient der Ring jetzt im Konzept des Internet der Dinge als Zahlungsinstrument, als Zugangskontrollausweis, Fernbedienung für andere intelligente Geräte usw. Somit erscheinen neue bequeme Anwendungsfälle für das Vertraute.



Intelligente Dinge sind heute ein globaler Trend. Dies wird durch statistische Daten belegt, die von verschiedenen Weltagenturen gesammelt wurden (siehe Links am Ende des Artikels). 



In diesem Artikel möchte ich anhand des Beispiels unserer Forschung bei der Entwicklung einer IoT-Plattform erläutern, mit welchen Aufgaben die Fintech-Richtung der Wallet-Anwendung arbeitet, mit welchen Problemen wir konfrontiert sind und wie wir bewährte Technologien der Kartenindustrie verwenden, um neue Produkte zu entwickeln.



Zunächst werde ich kurz und in einfachen Worten die Technologien beschreiben, auf denen unsere Plattform basiert. Wenn Sie mehr über diese Technologien erfahren möchten, finden Sie am Ende des Artikels Links. 



  1. , Secure Element — , 5-20 . , -, , - , . , SIM-, . ( ).



    , — . , .
  2. GlobalPlatform Card Specification — , .
  3. TSM  (Trusted Service Manager) — . .
  4. EMV — ( ), . , - , , .


Hier sind die wichtigsten Szenarien für die Interaktion eines Smartphones mit dem Gerät selbst, die wir in unsere Plattform integriert haben (in allen Szenarien steuert der Benutzer das tragbare Gerät über die Schnittstelle der mobilen Anwendung auf dem Smartphone): 



Das erste Szenario ist die Interaktion mit aktiven tragbaren Geräten. Tragbare Geräte werden als aktive Geräte bezeichnet, die über eine eigene Batterie verfügen (z. B. eine Batterie). In der Regel hat das Ding ein eigenes Betriebssystem und es gibt ein BLE-Modul für die Kommunikation mit einem Smartphone. Der Gerätehersteller stellt SDK und Zugriffsschlüssel für die Interaktion mit dem Sicherheitselement bereit. 



So funktionieren alle Smartwatches und Fitnessarmbänder mit kontaktloser Zahlungsfunktion. Alles ist einfach und klar - wir nehmen es und machen es. 



Das zweite Szenario ist interessanterIst die Interaktion mit passiven tragbaren Geräten. Tragbare Geräte werden als passive Geräte bezeichnet, die keine eigene Batterie haben. Diese Geräte werden von einem externen Magnetfeld gespeist, in das sie gestellt werden müssen. Dies kann das elektromagnetische Feld eines kontaktlosen Terminal-Lesegeräts oder die NFC-Antenne eines Smartphones sein. So können kontaktlose Bankkarten sicher als passive tragbare Geräte bezeichnet werden. 



Das Problem ist, dass Sie Ihre Bankkarte von einer Anwendung auf Ihrem Smartphone in ein passives tragbares Gerät laden müssen.



Wir unterbrechen dieses Szenario (bedingt) je nach Art des Smartphones:



  1. Alle Smartphones ohne NFC
  2. Android-Smartphone mit NFC
  3. iPhone mit NFC


Für den ersten Typ verwenden wir einen externen Leser, der sich in speziellen Personalisierungsterminals befindet. Kurz gesagt, das Personalisierungsterminal und die mobile Anwendung im Smartphone sind mit demselben Backend verbunden, das beide Clients synchronisiert. Das Token wird über das Personalisierungsterminal geladen, und der Benutzer sieht das Ergebnis in der Benutzeroberfläche für mobile Anwendungen.



Die Implementierung des Personalisierungsterminals kann unterschiedlich sein: Es kann sich um das Smartphone desselben Benutzers handeln, das über BLE oder USB mit einem externen Smartcard-Lesegerät verbunden ist, oder um ein autonomes externes Gerät (ein vollwertiger Computer mit angeschlossenem Lesegerät, Internetzugang und Steuerungssoftware). ...



Für den zweiten Typ (Android mit NFC) ist die Implementierung klar. In diesem Fall kann das Smartphone als Terminal verwendet werden, das passive Gerät über die NFC-Antenne mit Strom versorgt und ein Bankkarten-Token eingelegt werden.



In unserer Studie werde ich detailliert beschreiben, wie wir an der dritten Art von Smartphones (iPhones mit NFC) gearbeitet haben. Als tragbare Geräte verwendeten wir Schlüsselanhänger von ISBC , dem Partner, mit dem wir den Piloten starten.



Zweck der Studie



Können wir dem iOS Wallet- Benutzer ermöglichen , seine Bankkarte in ein tragbares Gerät zu laden, indem wir sie an das iPhone anschließen?



Also:



  1. Der Benutzer in der Anwendung "Wallet" gibt die Daten seiner Bankkarte ein
  2. Der Benutzer lehnt ein tragbares Gerät an die Rückseite eines iPhones
  3. Die Bankkarte wird in das tragbare Gerät geladen


Dementsprechend besteht die technische Aufgabe darin , über das ISO / IEC 7816- Protokoll (T = CL) zu bestimmen, ob es möglich ist, eine Bankkarte mit einem normalen iPhone und seiner NFC- Antenne in ein externes Sicherheitselement (Secure Element) zu laden .  Zusätzliche Aufgaben:







  1. Holen Sie sich ATR (Answer To Reset) des Chips, ohne ihn vom Lesegerät zu entfernen
  2. Holen Sie sich die UID (Unique Identifier) ​​des Chips


Diese Daten können nützlich sein, da sie häufig verwendet werden, um den Chip in den Systemen von Dienstanbietern zu identifizieren und Schlüssel von den sensiblen Daten der Chipanwendungen zu diversifizieren.



Was wir haben:



  • iPhone 8 mit iOS 13.5
  • Tragbares Testgerät - ISBC-Schlüsselanhänger mit integriertem JCOP 3 EMV P60-Chip und geladenen Applets von NXP :

    PPSE und einem Applet, das den M / Chip Advance implementiert - Kartenspezifikation Zahlung und Datenspeicherung v1.1;
  • Schlüssel vom Issuer Security Domain-Chip.


Entscheidung



Zu Beginn werden wir die Hauptaufgabe zerlegen, nämlich die Schritte festlegen, die erforderlich sind, um einen ganz normalen Schlüsselbund (fast) in ein vollwertiges Zahlungsmittel zu verwandeln:



  1. Herstellen einer Verbindung zwischen dem Chip und dem NFC- Modul des iPhone
  2. Installation von Mastercard M / Chip Advance- und PPSE- Applets auf dem Chip
  3. Applets personalisieren 


Verbindung herstellen



Hier werden wir über die Funktionen des in iOS 13 hinzugefügten Core NFC- Frameworks sprechen .

Übrigens wurden in iOS 14 keine wesentlichen Änderungen in Bezug auf das Thema des Artikels vorgenommen, sodass alles, was beschrieben wurde, für sie relevant ist.



In der dreizehnten Version des Apple-Betriebssystems war es also möglich, Daten von NFC- Tags nicht nur zu lesen , wie dies in iOS 12 der Fall war (jedoch nicht früher als in iOS 11, zuvor war eine Interaktion über NFC nur innerhalb von Apple Pay möglich), sondern auch zu schreiben und Kommunizieren Sie auch in der APDU-Befehlssprache mit jedem Chip, der einem der folgenden Standards entspricht:





Zu diesem Zweck wurden Core NFC zwei neue Klassen hinzugefügt: NFCNDEFReaderSession und NFCTagReaderSession .



Das erste wird verwendet, um mit NDEF-Tags zu interagieren, und das zweite wird für alles andere verwendet.



In unserem Fall ist dies ein Chip, der die GlobalPlatform Card Specification 2.2.1 und den ISO / IEC 7816-Standard unterstützt , was bedeutet, dass wir die zweite Klasse verwenden werden.



In der Dokumentation steht, was Sie tun müssen (außer natürlich Code zu schreiben), um mit dem Chip gemäß ISO 7816 zu kommunizieren:





Aber unten gibt es eine so interessante Einschränkung: Wir wollen es nur "fühlen", nachdem wir gelernt haben, was es genau bedeutet. Fügen Sie eine Zeile hinzu, z. B. "NFC-Verbindung zulassen" für den NFCReaderUsageDescription- Schlüssel in der Datei info.plist . Es funktioniert auch mit jedem anderen Wert dieses Schlüssels. 



Important

Core NFC doesn't support payment-related Application IDs.













[Hier in der linken Spalte, nicht der Schlüssel selbst, sondern seine Beschreibung, verbirgt XCode die formalen Namen.]



Wenn wir mit dem Chip wie mit einem ISO / IEC 7816- Gerät interagieren möchten , dann als Wert des Schlüssels com.apple.developer.nfc.readersession. iso7816.select-identifiers  geben die Liste der IDs aller Applets (Application Identifier oder AID) an, mit denen die Anwendung interagieren wird.                          





Hier ist zu verdeutlichen, dass diese Bezeichner nicht nur ein zufälliger Zeichensatz sind.

Hierbei handelt es sich um hexadezimale Zeichenfolgen, die Informationen zu der Anwendung enthalten, der sie zugewiesen sind.



AIDs können 5 bis 16 Byte lang sein (zwei Zeichen pro Zeile = ein Byte). Sie bestehen aus zwei Teilen: Der erste identifiziert den Anwendungsanbieter (für Mastercard ist es „A000000004“), der zweite gibt an, um welche Art von Produkt es sich bei diesem Anbieter handelt (für ein Produkt mit dem Namen „Mastercard“ ist es „1010“ und für Maestro beispielsweise „3060“ "). 



Außerdem müssen manchmal zusätzliche Informationen in die AID gestellt werden, z. B. wenn sich auf dem Chip zwei identische Anwendungen desselben Anbieters befinden, jedoch für verschiedene Banken. Hierfür wird Long AID (oder Extended AID) unterstützt. Solange die Länge der AID 16 Byte nicht überschreitet, können Sie alles darauf schreiben. Zum Beispiel haben wir Mastercard AID genommen und am Ende "TEST" hinzugefügt, das Ergebnis: "A0000000041010BB5445535401".



Die einzige AID, die nicht in der Liste aufgeführt ist, ist "325041592E5359532E444446303101".

Tatsächlich ist dies die übliche (nur im Hex-Format), wie sie sagen, Klartextzeichenfolge "2PAY.SYS.DDF01". Dies ist die AID PPSE, die per se kein Zahlungs-Applet ist. Es enthält nur die Umgebungsdaten, die für Zahlungsanwendungen erforderlich sind.



Applets installieren



Um Applets auf einem Chip zu installieren, benötigen Sie eine sichere Verbindung (Secure Channel Protocol oder SCP). Wir haben es hinter den Kulissen mit einem herkömmlichen PC / SC- Lesegerät und der Cardsmobile TSM- Plattform gemacht .



Selbst wenn Sie keines davon haben, können Sie dennoch versuchen, Ihr eigenes Applet auf einem Chip zu installieren - nur einem virtuellen.



Sie benötigen eine IDE mit JCOP Shell-Unterstützung und JavaCard-Emulator, zum Beispiel diese .



Erstellen Sie ein leeres Projekt, geben Sie die gewünschte AID an (z. B. 0000000000) und führen Sie sie aus.



Dann verstehen wir die Schritte:



  1. / card

    ATR abrufen, SELECT ohne ID senden, damit Card Manager ausgewählt wird;





  2. auth

    , ;



  3. ls ()

    , /;





  4. install [packageAID] [appletAID] [instanceAID]

    :



    packageAID — (Module), , «0000000000»

    appletAID — (Load File), , «000000000000»

    instanceAID — , , , «A0000000041010»;





  5. ls

    , :







Tatsächlich ist das Personalisieren eines Applets sehr einfach. Sie müssen lediglich die erforderlichen Zahlungsdaten laden. Dazu müssen Sie das Applet mit dem Befehl SELECT anhand seiner AID auswählen, eine sichere Verbindung herstellen und dem ausgewählten Applet den Befehl STORE DATA mit den darin enthaltenen Daten senden.



Kehren wir nun zur Liste der AIDs in der Datei info.plist zurück. Warum wird sie benötigt und wie genau wählt Core NFC das Applet aus, mit dem interagiert werden soll.



Es sieht aus wie das:



  1. Das Programm geht die Liste von oben nach unten durch.
  2. Für jede AID wird ein SELECT-Befehl generiert und gesendet.
  3. Die AID des ersten Applets, das mit "9000" geantwortet hat (der Status einer erfolgreichen Antwort, hier eine Liste aller möglichen Antworten ), wird in das Feld initialSelectedAID eines Objekts vom Typ NFCISO7816Tag geschrieben , das in das Array der erkannten Chips eingefügt wird


@available(iOS 13.0, *)

public protocol NFCISO7816Tag : NFCNDEFTag, __NFCTag {

   /**

    * @property initialSelectedAID The Hex string of the application identifier (DF name) selected by the reader when the tag is discovered.

    *                              This will match one of the entries in the «com.apple.developer.nfc.readersession.iso7816.select-identifiers»

    *                              in the Info.plist.

    */

   @available(iOS 13.0, *)

   var initialSelectedAID: String { get }


Außerdem können Sie ein solches Objekt aus dem Array auswählen und mit der sendCommand- Methode APDU-Befehle an das ausgewählte Applet senden .



Lassen Sie uns nun über diese Einschränkung sprechen:

  

Core NFC doesn't support payment-related Application IDs.


Das heißt, Core NFC unterstützt keine Zahlungs-AIDs, dh Kampf-AIDs, mit denen Zahlungsterminals arbeiten.



Natürlich können Sie der Liste info.plist eine Zahlungs-AID hinzufügen, aber Core NFC ignoriert diese und sendet kein SELECT dafür (übrigens hier eine Liste aller verwendeten AIDs ). Auf diese Weise schützt Apple seine Apple Pay-Technologie und verhindert, dass Entwickler von Drittanbietern auf die Zahlungsfunktionen des iPhones (und alles, was damit zu tun hat) zugreifen.



Problemumgehungen



Das erste, was mir in den Sinn kommt, ist, ob es möglich ist, info.plist nicht die AID des Zahlungs-Applets hinzuzufügen, sondern den AID Card Manager (Card Manager ist eine Gruppe von Diensten innerhalb des Betriebssystems des Chips, die die Karte verwalten und für Verwaltung und Sicherheit verantwortlich sind) Senden Sie ihm dann manuell den Befehl SELECT mit der AID des gewünschten Applets.



Hier sind wir auf die erste Gefahr gestoßen - Core NFC erlaubt nicht das Senden eines SELECT-Befehls, der eine AID enthält, die nicht in info.plist registriert ist .



Okay, wir haben A0000000041010 hinzugefügt, aber dies ist auch ein Fehler. Core NFC erlaubt nicht das Senden eines SELECT-Befehls, der eine Zahlungs-AID enthält, unabhängig davon, ob er sich in info.plist befindet oder nicht.



Mal sehen, wie die ID-Einschränkung funktioniert.



In info.plist haben wir folgende AIDs angegeben: 



1. A000000001510000                        	- GlobalPlatform Card Manager AID
2. 325041592E5359532E444446303101      - Proximity Payment System Environment (PPSE) 
3. A0000000041010                             	- Mastercard Credit/Debit (Global)
4. A00000000401                                 	- Mastercard PayPass
5. A00000000410101213                    	- Mastercard Credit
6. A00000000410101215                    	- Mastercard Credit
7. A00000000410101214                    	-   AID                 
8. A00000000410101216                    	-   AID 
9. A0000000041010121F                    	-   AID 
10. A0000000041010BB5445535401 	        -   Long AID
11. A0000000041010BB5445535405 	        -   Long AID
12. A000000004101FBB5445535401 	        -    AID                
13. A000000004101F1213                    	-    AID                 
14. A00000000F1010                             	-    AID
15. A0000000040F                                     -    AID


Wir haben 14 Zahlungs-Applets mit unterschiedlichen AIDs installiert (Punkte 2-11 - Zahlungs-AIDs) und versucht, die Card Manager SELECT-Befehle mit jeder dieser AIDs zu senden.



Die Nummern 12-15 wurden beantwortet .  



Es stellt sich heraus, dass die Einschränkung einem bestimmten AID-Präfix auferlegt wird, dessen Vorhandensein bestimmt, ob es sich um eine Zahlungskennung handelt oder nicht.



Schade, aber diese Methode ist nicht mehr gültig.



Die zweite von GlobalPlatform bereitgestellte Personalisierungsoption ist der Befehl INSTALL [zur Personalisierung].





Es wird an den Kartenmanager gesendet und enthält die AID des Applets, das personalisiert werden muss.



Anschließend können Sie STORE DATA-Befehle an Card Manager senden, der sie an die Zielanwendung weiterleitet.



Es gibt jedoch eine Einschränkung. Damit ein Applet diese Art der Personalisierung unterstützt, muss es die Schnittstelle org.globalplatform.Application implementieren .



Der Kartenmanager antwortete auf den Befehl INSTALL [zur Personalisierung] mit Mastercard Credit / Debit (Global) AID, der dem M / Chip Advance-Applet von NXP zugewiesen wurde , mit dem Fehler "6985" (Nutzungsbedingungen nicht erfüllt),



was bedeutet, dass Sie überprüfen müssen, ob er implementiert ist ob es sich um die Anwendungsschnittstelle handelt .



Zu diesem Zweck haben wir eine einfache Dummy-Anwendung geschrieben, die diese Schnittstelle implementiert. Wie erwartet wurde bei INSTALL [zur Personalisierung] mit "9000" geantwortet.



Als die Anwendung jedoch von den von der Anwendung implementierten Schnittstellen entfernt wurde, reagierte sie auf diesen Befehl "6985", wie dies beim M / Chip Advance-Applet der Fall ist.



Daher besteht das Problem genau darin, dass die NXP- Anwendung die für diese Art der Personalisierung erforderliche Schnittstelle nicht implementiert. Diese Methode verschwindet ebenfalls.



Zusätzliche Aufgaben



  1. Abrufen der UID des Chips

    Dies kann auf sehr einfache Weise erfolgen.

    Zu Beginn einer NFC- Sitzung sucht das Modul nach Chips, deren AIDs von Applets in info.plist registriert sind, und fügt sie einem Array hinzu.

    Danach können Sie einen von ihnen von dort abrufen. Wenn der Typ NFCISO7816Tag ist , verfügt er über ein Bezeichnerfeld, das die UID des Chips enthält. 



    /**
  * @discussion The hardware UID of the tag.
*/
var identifier: Data { get }


  2. Erhalten eines ATR- Chips

    Es scheint jedoch, dass Core NFC keine ATR empfangen kann , da es dafür keine separaten Tools im Framework gibt und Sie ATR nicht mit APDU-Befehlen erhalten können .


Schlussfolgerungen



Was steht unter dem Strich?



  1. ISO/IEC 7816 ( UID), Core NFC;
  2. , Apple ;
  3. , , iPhone, , Application — ;
  4. , AID — .


Wenn wir die eingangs gestellte Frage beantworten, können wir dem Wallet-Benutzer die Möglichkeit geben, seine Bankkarte in den Schlüsselanhänger zu laden, indem wir sie an das iPhone anschließen - nein, dies ist noch nicht möglich.



Als Teil der Aufgabe haben wir uns entschlossen, einen externen BLE-Leser zu verwenden, um einen Bankkarten-Token von einem iPhone in ein passives tragbares Gerät zu laden.



Hoffentlich wird Apple in Zukunft die Funktionen von NFC Core erweitern, um dies und eine Reihe anderer Tokenisierungs- und Zahlungsaufgaben in Anwendungen von Drittanbietern zu erfüllen. Allerdings jüngste Nachrichten Signale , dass dies unwahrscheinlich , dass in naher Zukunft geschehen.



Ein Nebeneffekt der Studie



Im Laufe der Arbeit wurde ein potenzielles Betrugsprogramm entwickelt, das mit Apple-Smartphones nicht reproduziert werden kann. Es ist jedoch durchaus möglich, es über ein Android-Smartphone mit NFC-Unterstützung und Host Card Emulation-Technologie zu implementieren.



Das Endergebnis ist: 



  • Das erste Smartphone wird als Terminal verwendet, dh es wird eine Verbindung zu Bankkarten hergestellt und mit deren Zahlungs-Applets interagiert.
  • das zweite Smartphone - als Zahlungsmittel (an der Kasse sieht es aus wie eine reguläre Zahlung mit einem Smartphone).


Mit diesem Schema können Sie eine Kettenbankkarte - Smartphone - Smartphone - Zahlungsterminal erstellen, nämlich:



  1. Das erste Smartphone ist an eine Bankkarte angeschlossen.
  2. Die zweite wird auf das Zahlungsterminal angewendet.
  3. Das zweite Smartphone emuliert eine Bankkarte, indem es vom Terminal gesendete APDU-Befehle an das erste Smartphone sendet .
  4. Das erste Smartphone überträgt diese Befehle an die angeschlossene Bankkarte und sendet seine Antworten an das zweite Smartphone.
  5. Das zweite Smartphone sendet die empfangenen Antworten an das Terminal.
  6. Die Zahlung wurde geleistet.


Das heißt, möglicherweise kann ein Betrüger ein Smartphone in die Tasche stecken und den Kauf bezahlen. Seid vorsichtig!



Um nicht Opfer eines solchen betrügerischen Vorhabens zu werden, können Sie beispielsweise Bankkarten auf Ihr Smartphone übertragen und kein Plastik mit sich führen.



Anstelle einer Schlussfolgerung



Ich habe versucht, den Artikel in einer einfachen Sprache zu schreiben, ohne zu tief in die Terminologie des Themenbereichs einzusteigen. Darin habe ich eines der innovativen Projekte beschrieben, an denen wir arbeiten, den Themenbereich und ein wenig Forschung zu den neuen Funktionen des iOS Core NFC-Frameworks.



Jedes Feedback ist willkommen: Fragen, Bewertungen, Kommentare, Ergänzungen, konstruktive Kritik.



Nützliche Links



Wenn Sie sich für das im Artikel beschriebene Thema interessieren, finden Sie unten einige Links für eine detailliertere Studie:



  1. Buch von I. M. Goldovsky " Bank Microprocessor Cards "

  2. Konzept EMV Payment Tokenisation

  3. Artikel mit Analyse des IoT-Marktes: 



More articles:


All Articles