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 auf dem neuesten Stand. Diese Sicherheitsmaßnahme reduziert die Risiken Screenshoterstellung von Barcodes, insbesondere Diebstahl von Tickets oder nicht autorisierte Tickets für den Weiterverkauf. 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 in den Typ RotatingBarcode.

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 Nutzergerät 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 <ph type="x-smartling-placeholder">
      </ph>
    • 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 Barcodenutzlast angegeben ist
  3. Statischer Barcode: Wenn eine Barcodenutzlast angegeben ist

Wenn Sie mehrere Einlösungsnutzlasten angeben, können Sie sicherstellen, dass alle Benutzer unterstützt werden, Auswirkungen auf die Sicherheit haben kann. Insbesondere die Verwendung eines statischen Barcodes als Fallback auf einen rotierenden Barcode eliminiert die meisten Sicherheitsvorteile der Verwendung rotierenden Barcodes. Ein statisches Barcode-Fallback wird nur in Webansichten angezeigt oder bei Clients, 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 mehrere Abläufe, darunter:

  • Boardingklassen beim Speichern oder im Voraus erstellen
  • Senden der vollständigen Objekte im JWT oder Speichern der Objekte vor der und dann im JWT anhand der ID darauf verweisen.
  • Objekte nach dem Speichern aktualisieren

Das vorgeschlagene Feld „rotatingBarcode“ ist mit allen diesen Abläufen kompatibel. Um die Sicherheit zu verbessern, 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, Das resultierende JWT enthält nicht den geheimen Schlüssel des rotierenden Barcodes.
  • 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 dieses Zeitraums aktualisiert wird im normalen Geschäftsbetrieb.

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

Sequenzdiagramm für die Verwendung rotierender Barcodes