Rotierende Barcodes

Einführung

Rotierende Barcodes sehen wie normale Barcodes aus, ändern sich jedoch regelmäßig. in der Regel jede Minute. Das Terminal/Lesegerät ist so programmiert, dass die letzte. Durch diese Sicherheitsmaßnahme können Risiken minimiert werden, die mit der Screenshoterstellung von Barcodes einhergehen, insbesondere in Bezug auf den Diebstahl oder den nicht autorisierten Weiterverkauf von Tickets. Rotierende Barcodes können auch als Fallback für Geräte dienen, bei denen Smart-Bonus nutzen, da sie NFC (fehlende Hardware) nicht unterstützen Software deaktiviert).

API-Referenz

Technische Details zu rotierenden Barcodes finden Sie unter RotatingBarcode-Typ.

Beispielnutzlast

JSON 
{
  "rotatingBarcode": {
    "type": "QR_CODE",
    "valuePattern": "MyRotatingBarcode-{totp_timestamp_seconds}-{totp_value_0}",
    "alternateText": "Ticket#: 1234567890",
    "totpDetails": {
      "algorithm": "TOTP_SHA1",
      "periodMillis": "3000",
      "parameters": [
        {
          "key": "3132333435363738393031323334353637383930",
          "valueLength": "8"
        }
      ]
    }
  }
}

Fallback-Mechanismen

Auf dem Gerät des Nutzers wird jeweils nur ein Einlösungsmechanismus verwendet, je nachdem, wie die Karte bzw. das Ticket konfiguriert ist und welche Funktionen das Gerät hat. Die folgenden Einlösungsarten werden verwendet (in der Reihenfolge ihrer Priorität):

  1. Smart-Bonus: Wenn eine Nutzlast für Smart-Bonus angegeben ist und das Gerät dies unterstützt NFC/HCE
    • Diese Einstellung kann vom Nutzer überschrieben werden, indem er auf „Code anzeigen“ klickt. erzwingt die Anzeige des rotierenden/statischen Barcodes.
  2. Rotierender Barcode: wenn eine rotierende Barcode-Nutzlast angegeben ist
  3. Statischer Barcode: Wenn eine Barcodenutzlast angegeben ist

Wenn du mehrere Nutzlasten für die Einlösung angibst, können alle Nutzer unterstützt werden. Allerdings hat dies möglicherweise Auswirkungen auf die Sicherheit. Vor allem, wenn ein statischer Barcodes als Fallback für einen rotierenden Barcode verwendet wird, fallen die meisten Sicherheitsvorteile der Verwendung rotierenden Barcodes weg. Ein statischer Barcode als Fallback wird nur in Webansichten oder auf Clients angezeigt, die keine rotierenden Barcodes unterstützen. Heute gehen wir davon aus, alle Google Wallet-Clients müssen rotierende Barcodes unterstützen.

Ablauf speichern

Die Google Wallet API bietet verschiedene Abläufe. Hierzu gehören:

  • Geschenkkartenklassen beim Speichern oder im Voraus erstellen
  • Vollständige Objekte im JWT senden oder Objekte im Voraus speichern und dann durch die ID im JWT darauf verweisen
  • Objekte nach dem Speichern aktualisieren

Das vorgeschlagene Feld „rotatingBarcode“ ist mit jedem dieser Abläufe kompatibel. Zur Verbesserung der Sicherheit empfehlen wir jedoch Folgendes:

  • Rufe die object:insert API auf, um die Karte bzw. das Ticket in den Google Wallet-Server und konfiguriere die Schaltfläche „Zu Google Wallet hinzufügen“, um im JWT anhand der ID auf das jeweilige Objekt verweisen. Dadurch wird sichergestellt, dass das resultierende JWT nicht den geheimen Schlüssel des rotierenden Barcodes enthält.
  • Verwenden Sie einen geheimen OTP-Schlüssel für eine einzelne Karte / ein einzelnes Ticket
  • Wenn der Schlüssel nicht aktualisiert wird, ist er voraussichtlich für die folgende Lebensdauer gültig: die Karte bzw. das Ticket. Wir erwarten nicht, dass dieser Schlüssel im Laufe im normalen Geschäftsbetrieb.

Das folgende Sequenzdiagramm veranschaulicht den Fluss zwischen den verschiedenen Akteuren. für eine typische Integration:

Sequenzdiagramm zur Verwendung rotierender Barcodes