BringPass
Lesegerät testen
Ein echtes Beispiel scannen. Exakte Bytes oder Zeichenfolge, führende Nullen, Trennzeichen und Abschlusszeichen erfassen. Auch die physische Oberfläche testen, einschließlich eines Smartphone-Displays.
Was funktioniert – und unter welchen Bedingungen
Kompatibilität ist ein Testergebnis.
Kompatibilität ist ein Testergebnis.
Kein pauschales Versprechen.
Medium, Lesegerät, Backend und Registrierungsregeln müssen zusammenpassen. „NFC“ oder „QR“ auf der Verpackung reicht nicht.
Diese Fassung ist ein Website- und Designpaket.
Lesegerätetreiber, Wallet-App und Kartenfirmware sind nicht enthalten. „Bestehende Technik“ beschreibt unten einen möglichen Nutzungsweg, keine sofort verfügbare Produktunterstützung durch BringPass.
| Technik | Möglicher Einstieg | Voraussetzung / Grenze | Sicherheit und Änderungsbedarf |
|---|---|---|---|
| Statischer Barcode / einfacher QR-Code | Einen vorhandenen Code mit Erlaubnis anders anzeigen oder einen eigenen Wert registrieren. | Der Scanner akzeptiert Format und Oberfläche; das Backend akzeptiert Format, Wertebereich und Eindeutigkeit. Manche optischen Leser lesen Displays nicht zuverlässig. | Möglicherweise ohne Änderungen nutzbar. Bleibt ein kopierbarer Zugangswert. |
| Code 128 / Code 39 / EAN-artige Felder | Nur eine dokumentierte, vom Anbieter zugelassene Codierung verwenden. | Zeichensätze, Prüfziffern, Präfixe und Feldlängen beachten. Keine extern vergebenen Nummern erfinden oder Werte stillschweigend kürzen. | Kollisionen bei der Registrierung auflösen. Kleine Felder erlauben kein Versprechen globaler Eindeutigkeit. |
| Nachschlagen über NFC-Seriennummer / UID | Eine kompatible physische Karte über den üblichen Ablauf registrieren. | Frequenz, Protokoll, UID-Länge und Lesegeräteausgabe müssen passen. 125-kHz-Transponder sind kein NFC. | Dieselbe UID ermöglicht Verknüpfungen. Smartphone-HCE liefert nicht ohne Weiteres eine stabile UID. |
| Geschützte Smartcard-Anwendung | Der Anbieter richtet eine kompatible Anwendung mit autorisierten Schlüsseln ein. | Leserprotokoll, Anwendungsstruktur, Schlüsselverantwortung und Regeln für Zugangsmittel müssen zusammenpassen. | Konfiguration, Provisionierung oder Integration. Keine Schlüsselumgehung und kein universeller Klon. |
| Dynamischer / signierter QR-Code | Die autorisierte Ausgabe des Ausstellers weiternutzen oder eine Prüfung integrieren. | Das Bild zu ändern reicht nicht; das Backend muss den Inhalt verstehen und prüfen. | Eigene wechselnde Nachweise funktionieren nicht unverändert mit einem Backend für statische Werte. |
| WebAuthn / Passkeys | Den nativen Browserablauf des Anbieterportals verwenden. | Anbieterbindung, geprüfter Ursprung, Challenge und Kontobindung bleiben wesentlich. | Webintegration erforderlich. Ersetzt nicht automatisch das Protokoll eines Türlesers. |
| Natives Smartcard- / NFC-Profil | Mögliche zukünftige Anwendung für ein Sicherheitselement. | Provisionierung, authentifizierter Anbieterkontext, APDU-Profil und unterstützte Chips müssen spezifiziert werden. | Logische native Nachrichten sind entworfen; eine hardwarespezifische NFC/APDU-Anbindung ist hier weder implementiert noch standardisiert. |
| Zukünftiger elektronischer Token | Eigenes Display + Sicherheitselement + physische Tasten. | Prototyp, Funk- und Displaytests, Energiebudget, Provisionierung und Wiederherstellung sind noch offen. | Nur ein Konzept. Keine Aussage zu Preis, Verfügbarkeit oder Batterielaufzeit. |
Referenzen: Android HCE · W3C WebAuthn · Apple NFC & SE .
Das Smartphone ist kein universeller Kartenemulator
Flexibel beim Anzeigen.
Flexibel beim Anzeigen.
Begrenzt beim Funk.
Ein Smartphone kann unterschiedliche optische Werte anzeigen, ohne ein Lesegerät zu verändern, das diese bereits akzeptiert. Die NFC-Unterstützung ist enger: Android HCE ermöglicht unterstützte ISO-DEP-/APDU-Anwendungsdialoge; die präsentierte UID darf nicht als stabile Identität vorausgesetzt werden.
Apples sichere kontaktlose Schnittstellen unterliegen Zulassungs-, Berechtigungs- und Plattformvorgaben. Vor einer Festlegung auf eine iPhone-Implementierung den geplanten Anwendungsfall und die Einsatzregion prüfen.
Eine passive Smartcard kann vom Lesegerät mit Energie versorgt werden. Das bedeutet nicht, dass jeder NFC-Tag signieren, Schlüssel importieren, beliebige Anwendungen ausführen oder neu programmiert werden kann. Zuerst Chip und Provisionierungsmodell auswählen.
Referenzen: Android-Plattformdokumentation · Apple-Plattformvorgaben .
Den ganzen Weg testen
Kompatibilitäts-Arbeitsblatt herunterladen
Backend testen
Registrieren, Duplikate erkennen, authentifizieren, ersetzen, sperren und zurückrollen. Grenzen für Zugangsmittel je Konto und die Aktualisierung von Offline-Caches prüfen.
Regeln prüfen
Bestätigen, dass externe Medien erlaubt sind, die Zugangssicherheit ausreicht, Mitarbeitende eine Alternative haben und keine Sicherheitszusage über den tatsächlichen Mechanismus hinausgeht.