Wie authentifiziert sich Code an einem passwortgeschützten Tag?
Indem er den Authentifizierungsbefehl des Chips mit dem Passwort sendet, die Antwort des Chips prüft und erst dann die geschützten Seiten liest oder schreibt, alles auf derselben Verbindung. Die Authentifizierung dauert höchstens so lange, wie der Tag versorgt bleibt, jede neue Verbindung beginnt also ohne sie. Der Befehl selbst gehört dem Chip und nicht dem Tag-Typ.
Die Abfolge
Ein passwortgeschützter Tag verweigert die geschützten Vorgänge, bis er das richtige Passwort erhält, auf den Chips, die eines anbieten; das Setzen und sein Umfang stehen auf der Seite zum Passwort. Die Seite des Codes ist eine kurze Abfolge auf einer einzigen Verbindung.
Er verbindet sich, mit NfcA unter Android oder über eine Tag-Sitzung unter iOS, und sendet den Authentifizierungsbefehl des Chips mit dem Passwort, über transceive() oder sendMiFareCommand. Er prüft die Antwort: Auf der Familie NTAG21x kommt das 32 Bit lange Passwort mit einer 16 Bit langen Bestätigung, PACK, laut dem Datenblatt zum NTAG213 auf wakdev.com, und der Code vergleicht die empfangene Bestätigung mit der, die er eingestellt hat. Erst dann liest oder schreibt er die geschützten Seiten, bevor er schließt.
Der Befehl gehört zu keinem Tag-Typ. Sein Code und sein Format gehören dem Chip, und NTAG21x, MIFARE Ultralight C, ICODE SLIX und NTAG 424 DNA haben jeweils ihre eigenen; die Chip-Datenblätter auf wakdev.com verweisen auf die Unterlagen, die sie festlegen. Auf Chips nach ISO/IEC 15693 mit Passwörtern liegen die Befehle, die sie verwalten, im Bereich der eigenen Befehle, wie die Seite zur ISO/IEC 15693 erklärt.
Was die Authentifizierung beendet
Ein passiver Tag bezieht seine Energie aus dem Feld des Lesegeräts, wie die Seite zur Versorgung erklärt, und eine Authentifizierung ist ein Zustand, den der Chip hält. Sie endet spätestens, wenn der Tag das Feld verlässt; das Datenblatt des Chips sagt, welche anderen Ereignisse sie beenden.
Ein zweiter Versuch beginnt also von vorn. Nach TagLostException unter Android oder readerTransceiveErrorTagConnectionLost unter iOS ist der Tag, der zurückkommt, nicht authentifiziert, und Code, der mit dem geschützten Schreibvorgang fortfährt, bekommt eine Weigerung. Dasselbe gilt für eine neue Tag-Sitzung unter iOS und für das neue Objekt Tag, das Android jedes Mal anlegt, wenn der Tag wieder in Reichweite kommt.
Halten Sie die Authentifizierung und die Vorgänge, die sie freigibt, auf einer Verbindung und einer Technologieklasse. Eine andere Klasse zu öffnen kann Android dazu bringen, den Tag neu auszuwählen: Im quelloffenen Stack kann der Code der Verbindung das bei ISO-DEP- und MIFARE-Classic-Tags tun, wenn die neue Klasse eine andere Schnittstelle des Controllers braucht, und tut bei einem Type-2-Tag nichts. Ob eine Neuauswahl die Authentifizierung beendet, legt das Datenblatt des Chips fest, und der Stack eines Telefonherstellers kann anders entscheiden, auf einer Klasse zu bleiben ist also die Wahl, die auf jedem Telefon hält.
Wo das Passwort lebt
Der Code sendet das Passwort, er muss es also halten. Ein einziges, in eine Anwendung einkompiliertes Passwort steckt in jeder Kopie der Anwendung, und wer es herauszieht, kann jeden Tag umschreiben, den es schützt. Ein Passwort je Tag verschiebt das Problem in eine Tabelle, die die Anwendung holt, die Aufzeichnung, die die Seite zum Passwort eine Datenbank nennt, die Sie nicht verlieren dürfen.
Ein Passwort ist zudem kurz. Das Passwort der NTAG21x ist 32 Bit lang, und manche Chipfamilien begrenzen die misslungenen Versuche, eine Einstellung, die die Seite zum Passwort dort empfiehlt, wo es sie gibt.
Nichts davon weist die Echtheit des Tags gegenüber der Anwendung nach. Eine Kopie des Inhalts trägt kein Passwort, wie die Seite zu Passwort und Authentifizierung erklärt, eine Anwendung, die wissen muss, ob ein Tag echt ist, braucht also einen Chip, der eine kryptografische Aufgabe beantwortet.
Was die Schnittstellen der Plattform nicht tun
Keine der NDEF-Schnittstellen der beiden Plattformen nimmt ein Passwort. Ndef.writeNdefMessage() unter Android und writeNDEF unter iOS schreiben auf einen Tag, der das Schreiben annimmt, und scheitern auf einem geschützten Tag wie jeder verweigerte Schreibvorgang, der Fehlschlag, den die Seite zum Schutzfehler von der Seite der Nutzenden beschreibt.
Der verlässliche Weg ist, sich mit einem rohen Befehl zu authentifizieren und die geschützten Seiten ebenfalls mit rohen Befehlen zu schreiben, was heißt, die NDEF-Bytes zu bauen und sie in einer sicheren Reihenfolge zu schreiben, wie die Seite zu abgebrochenen Schreibvorgängen beschreibt. Web NFC bietet keinen der beiden Schritte.
Häufige Fragen
Kann Ndef.writeNdefMessage auf einen passwortgeschützten Tag schreiben?
Nicht von sich aus. Die NDEF-Schnittstellen nehmen kein Passwort, authentifizieren Sie sich also zuerst mit einem rohen Befehl und schreiben Sie auf derselben Verbindung, sicherheitshalber mit rohen Befehlen.
Warum scheitert mein Schreibvorgang nach einem zweiten Versuch?
Der Tag hat das Feld verlassen und kam nicht authentifiziert zurück. Senden Sie den Authentifizierungsbefehl erneut, bevor Sie die geschützten Vorgänge ausführen.
Schützt das Passwort den Inhalt vor dem Lesen?
Nur auf Chips und in Einstellungen, die das Lesen schützen. Die meisten Konfigurationen schützen allein das Schreiben, wie die Seite zum Passwort erklärt.
Kann eine Anwendung das Passwort geheim halten?
Nicht vor jemandem, der es aus der Anwendung herauszieht. Jede Anwendung, die sich authentifiziert, hält das Passwort, das sie sendet, behandeln Sie es also als Sperre gegen beiläufiges Umschreiben.