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 nur der aktuelle Barcode akzeptiert wird. 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, die Smart-Bonus nicht nutzen können, da NFC nicht unterstützt wird (fehlende Hardware oder deaktivierte Software).

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 bei Smart-Bonus festgelegt ist und das Gerät NFC/HCE unterstützt
    • Diese Einstellung kann vom Nutzer durch Klicken auf „Code anzeigen“ überschrieben werden. Dadurch wird die Anzeige des rotierenden Barcodes oder statischen Barcodes erzwungen.
  2. Rotierender Barcode: wenn eine rotierende Barcode-Nutzlast angegeben ist
  3. Statischer Barcode: wenn eine Barcode-Nutzlast 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. Wir gehen davon aus, dass alle Google Wallet-Clients rotierende Barcodes unterstützen.

Ablauf speichern

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

  • Angebotsklassen 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 einzufügen. Konfiguriere dann die Schaltfläche „Zu Google Wallet hinzufügen“, damit in deinem JWT auf das spezifische Objekt anhand der ID verwiesen wird. 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 oder ein einzelnes Ticket.
  • Es wird erwartet, dass der Schlüssel für die Lebensdauer der Karte bzw. des Tickets gültig ist, solange er nicht aktualisiert wird. Es wird nicht erwartet, dass dieser Schlüssel während des normalen Betriebs aktualisiert wird.

Das folgende Sequenzdiagramm veranschaulicht den Ablauf zwischen den verschiedenen Akteuren bei einer typischen Einbindung:

Sequenzdiagramm für die Verwendung von rotierenden Barcodes