8-stellige BINs und PCI DSS

Am 1. April 2022 werden die Kartenorganisationen Visa und Mastercard die BIN (Bank Identification Number) ihrer Karten weltweit von 6 auf 8 Stellen ausdehnen. Von einer 16-stelligen Kreditkartennummer (Primary Account Number, PAN) dienen dann in Zukunft die ersten 8 Stellen zur Identifikation des Kartenherausgebers. Die BIN wird an vielen Stellen genutzt, wo die Verwendung der vollständigen PAN nicht nötig ist – z.B. für das Routing von Transaktionen oder für Reportings.

BINs und PCI DSS

Überall dort, wo eine vollständige PAN genutzt wird, müssen die Systeme, Umgebungen, Prozesse und Personen die Anforderungen des Datensicherheitsstandards PCI DSS (Payment Card Industry Data Security Standard) erfüllen. So sinnvoll der Schutz der PAN durch den PCI DSS ist – für die BIN ist er nicht notwendig.

Im PCI DSS ist daher beschrieben, unter welchen Bedingungen für Teile der PAN nicht der gleiche Schutz wie für die volle PAN notwendig ist. Wird nicht die volle PAN gespeichert, verarbeitet oder übertragen, sondern nur einige Stellen davon, spricht man im PCI DSS von „Trunkierung“. Ist zwar die volle PAN im Hintergrund gespeichert, aber in einer Applikation werden nicht alle Stellen angezeigt, spricht man im PCI DSS bei der Anzeige von „Maskierung“. Im Alltag wird für beide unterschiedlichen Maßnahmen auch der Begriff „ausgeixt“ verwendet; aus Sicht des PCI DSS muss man diese aber unterscheiden.

Für Trunkierung und Maskierung galten bisher folgende Regeln:

• Maskierung: PCI DSS-Anforderung 3.3 besagt, dass maximal die ersten sechs und letzten vier Stellen („first 6, last 4“) der PAN angezeigt werden dürfen, solange es keinen Business Need für die Einsicht in die volle PAN gibt.
• Trunkierung: In PCI DSS-Anforderung 3.4 wird Trunkierung als Beispiel für die Unkenntlichmachung von PANs benannt, aber nicht genauer definiert. Die erlaubten Formate werden jeweils von den internationalen Zahlkarten-Organisationen festgelegt und vom PCI SSC im FAQ-Eintrag #1091 zusammengefasst. Die meisten Zahlkarten-Organisationen hatten sich dabei auf die Regel „first 6, any other 4“ geeinigt, die viele Jahre Bestand hatte.

Änderung der Regeln für Trunkierung und Maskierung

Aufgrund der Umstellung auf 8-stellige BINs und der Notwendigkeit vieler Unternehmen, diese zu verarbeiten, haben die Zahlkarten-Organisationen ihre Vorgaben nun aber geändert. In der aktuellen Zusammenfassung im FAQ-Eintrag des PCI SSC ist nun definiert, dass für 16-stellige PANs bei der Trunkierung „first 8, any other 4“ zulässig ist.
Die (Test)Kartennummer 4012888888881881 dürfte dann in Zukunft z.B. in der Form 40128888xxxx1881 gespeichert und verarbeitet werden – es reicht aus, wenn beliebige vier Stellen hinter der BIN ausgeixt sind.
Lediglich für kürzere PANs bleibt es bei den bestehenden Regeln „first 6, any other 4“ (Discover) bzw. „first 6, last 4“ (American Express).  Bei der Maskierung wird eine entsprechende Anpassung der PCI DSS-Anforderung mit der Umstellung auf PCI DSS v4.0 erwartet.

Aus Sicherheitssicht ist das Ausixen so weniger Stellen keine Verbesserung – aus der Business-Perspektive ist die Änderung aber wohl notwendig. Es bleibt zu hoffen, dass dies in der Gesamtsicht durch andere Sicherheitsmaßnahmen ausgeglichen wird.
Auf jeden Fall stehen in Zukunft die Anforderungen des PCI DSS der Verwendung einer 8-stelligen BIN nicht im Wege.

Vorsicht bei der Kombination verschiedener Formate

Händler und Dienstleister, die mit trunkierten Kartendaten arbeiten, sollten – unabhängig von der Länge der BIN – darauf achten, den Schutz der Kartendaten nicht durch die Vermischung verschiedener Formate zu schwächen.

• Es muss darauf geachtet werden, dass die erweiterten Trunkierungsformate nur für 16-stellige PANs gelten. Die Länge der PAN muss also für die Trunkierung bei der Speicherung berücksichtigt werden.
• Trunkierungsformate wie „first 6, any other 4“ erlauben theoretisch das Vorliegen unterschiedlicher trunkierter Versionen der gleichen PAN. Die oben angeführte Kartennummer könnte in einem System als 40128888xxxx1881 gespeichert sein, in einem anderen als 401288888888xxxx. Das ist nicht verboten – es muss jedoch darauf geachtet werden, dass keiner ohne entsprechenden Business Need die beiden Versionen zusammenführen kann und somit weitere Stellen der PAN – bis hin zur vollständigen Kartennummer – rekonstruieren kann.
  Dies gilt genauso, wenn für Maskierung und Trunkierung unterschiedliche Formate verwendet werden.
• Werden in einer Umgebung sowohl trunkierte PANs als auch die Hash-Werte von PANs gespeichert, so sind die beiden Werte an sich erst einmal unkritisch. Lassen sich die trunkierten PANs und ihre Hash-Werte jedoch in Verbindung bringen, lässt sich über Rainbow Tables leicht die ursprüngliche volle PAN rekonstruieren. Auch in diesem Fall muss also über zusätzliche Maßnahmen die Möglichkeit der Zusammenführung der beiden Versionen verhindert werden.