Zum Inhalt

47-Tage-Zertifikate sind im Anmarsch. Sind Sie bereit?

Jetzt handeln →

Zahlungs-HSMs: Die Zukunft der Zahlungssicherheit

Zahlungs-HSMs – Die Zukunft der Zahlungssicherheit

Der Schutz von Kundendaten ist von entscheidender Bedeutung, um Ihren Kunden ein Gefühl der Sicherheit zu vermitteln und Missbrauch zu verhindern. Dies gilt insbesondere für die Zahlungsbranche. Institutionen wie Banken, Geldautomatenbetreiber und andere Organisationen, die Kundenzahlungsdaten verarbeiten, müssen deren Sicherheit gewährleisten, insbesondere wenn diese in ihren Datenbanken gespeichert sind. Hardware-Sicherheitsmodule (HSMs) für Zahlungen sind zertifizierte Hardware-Appliances, die kryptografische Schlüssel ausschließlich innerhalb einer manipulationssicheren Umgebung generieren, speichern und anwenden. PIN-Blöcke, Kartenprüfwerte und Schlüsselaustauschmaterialien werden in der Hardware so verwahrt, dass sie von keiner Software im Klartext extrahiert werden können. Zahlungsdienstleistern, Acquirer-Banken und Kartennetzwerken wird empfohlen, PCI-PTS-HSM-zertifizierte Hardware einzusetzen und TR-31-Schlüsselblöcke für den gesamten symmetrischen Schlüsselaustausch zu implementieren, um die PCI-PIN-Sicherheitsanforderungen vor dem nächsten Bewertungszyklus zu erfüllen.

Kurzantwort: Was ist ein Payment-HSM und warum ist es erforderlich?

Ein Payment-HSM ist eine nach FIPS 140-2 oder 140-3 und PCI PTS HSM zertifizierte Hardware-Appliance, die kryptografische Zahlungsoperationen ausführt: PIN-Übersetzung, Generierung von Kartenprüfwerten, Schlüsselaustausch mittels TR-31 und TR-34 sowie Schlüsseleinspeisung in Geldautomaten. Im Gegensatz zu einem Allzweck-HSM ist jeder Schlüssel im Payment-HSM typisiert und an eine spezifische Operation gebunden, wodurch Missbrauch über verschiedene Funktionen hinweg verhindert wird. Payment-HSMs sind gemäß den PCI-PIN-Sicherheitsanforderungen vorgeschrieben und bilden die Basiskontrolle für alle Organisationen, die PIN-basierte Transaktionen verarbeiten. Die spezifische Rolle von Payment-HSMs bei der Verhinderung von Datenschutzverletzungen wird im Artikel „ Die Rolle von Payment-HSMs bei der Verhinderung von Datenschutzverletzungen“ erläutert . Informationen zum HSM-Hosting ohne eigene Hardware finden Sie unter „HSM-as-a-Service“.

Angriffe mit Schwerpunkt auf dem Zahlungsverkehr

In der Zahlungsbranche existieren zahlreiche Standards und Vorschriften, die sicherstellen sollen, dass Unternehmen in diesem Sektor die korrekten Verfahren zum Schutz von Kundendaten einhalten. Standards wie PCI-DSS (Payment Card Industry Data Security Standard) , SOX (Sarbanes-Oxley Act) und DSGVO (Datenschutz-Grundverordnung) sowie die Standards des NIST (National Institute of Standards and Technology) dienen dem Schutz von Zahlungsdaten und anderen sensiblen Kundendaten.

Es gibt eine Reihe verschiedener Angriffsarten, die auf den Zahlungsverkehr abzielen. Aus diesem Grund haben Cybersicherheitsexperten und Aufsichtsbehörden zahlreiche Methoden entwickelt, um diese Angriffe abzuwehren.

  • Man-in-the-Middle-Angriffe

    Man-in-the-Middle-Angriffe sind branchenübergreifend verbreitet. Mit den richtigen Schutzmaßnahmen lassen sie sich jedoch abwehren. Wie der Name schon sagt, funktioniert ein Man-in-the-Middle-Angriff folgendermaßen: Wenn der Absender einer Datei Daten an den Empfänger sendet, fängt der Angreifer die Daten während der Übertragung ab und stiehlt sie, bevor sie ihr Ziel erreichen. Sind die Daten vor der Übertragung verschlüsselt, kann zwar ein Man-in-the-Middle-Angriff stattfinden, der Angreifer kann die Daten jedoch erst lesen oder nutzen, wenn er auch den Verschlüsselungsschlüssel erlangt.

  • Gestohlene Zugangsdaten / Phishing-Angriffe

    Phishing-Angriffe beinhalten das Versenden gefälschter E-Mails mit Links zu scheinbar vertrauenswürdigen Webseiten. Sobald ein Nutzer seine Anmeldedaten eingibt, werden diese vom Angreifer abgefangen und für den Zugriff auf das Konto des Opfers missbraucht. Daher sind Benutzerschulungen und Multi-Faktor-Authentifizierung unerlässliche Ergänzungen zu HSM-basierten kryptografischen Sicherheitsvorkehrungen.

  • Ausnutzung von Sicherheitslücken

    Die softwarebasierte Speicherung von Verschlüsselungsschlüsseln birgt das Risiko, dass diese an beliebiger Stelle im System ausgenutzt werden können. Die einzig zuverlässige Lösung ist der Einsatz eines Hardware-Sicherheitsmoduls , das die Schlüssel in Hardware speichert und sie niemals dem Betriebssystem oder der Anwendungsschicht zugänglich macht, wo Schwachstellen in Softwarekomponenten einen Weg zur Schlüsselextraktion eröffnen.

  • Brute-Force-Methode

    Bei Brute-Force-Angriffen werden alle Kombinationen von Passwörtern oder Schlüsseln ausprobiert, bis der richtige Wert gefunden ist. Bei Zahlungs-HSMs verhindern Manipulationsschutzmechanismen und hardwareseitig festgelegte Wiederholungslimits diese Art von Angriff auf in der Hardware gespeicherte Schlüssel. Bei der Benutzerauthentifizierung an Zahlungsportalen ist die Kontosperrung nach einer geringen Anzahl fehlgeschlagener Versuche die Standardgegenmaßnahme.

Was sind HSMs?

Hardware-Sicherheitsmodule (HSMs) sind Geräte, die kryptografische Schlüssel speichern und kryptografische Operationen innerhalb einer manipulationssicheren, zertifizierten Umgebung durchführen. Verschlüsselung ist der Prozess, sensible Daten mithilfe eines Verschlüsselungsschlüssels in Geheimtext umzuwandeln, sodass nur autorisierte Personen, die über den entsprechenden Schlüssel verfügen, den Klartext wiederherstellen können. Mithilfe von Verschlüsselungsschlüsseln können Kundendaten durch einen Verschlüsselungsalgorithmus geleitet werden , der die Daten anschließend in Geheimtext umwandelt, den nur der Schlüsselinhaber entschlüsseln kann.

Es gibt zwei verschiedene Arten der Verschlüsselung: symmetrische und asymmetrische Verschlüsselung . Die symmetrische Verschlüsselung verwendet einen einzigen gemeinsamen Schlüssel für Ver- und Entschlüsselung und dient dem Schutz großer Datenmengen sowie innerhalb von Zahlungsschlüsselhierarchien für Arbeitsschlüssel. Die asymmetrische Verschlüsselung verwendet ein mathematisch verknüpftes Schlüsselpaar: einen öffentlichen Schlüssel, der allen Beteiligten zugänglich ist, und einen privaten Schlüssel, der vom Besitzer geheim gehalten wird. Der öffentliche Schlüssel dient der Verschlüsselung bzw. Verifizierung, der private Schlüssel der Entschlüsselung bzw. Signierung. Zahlungs-HSMs unterstützen beide Arten und verwenden sie für unterschiedliche Teile des Zahlungsprozesses.

Bei einem HSM werden die Schlüssel direkt auf der Hardware gespeichert. HSMs werden in Rechenzentren unter Verschluss aufbewahrt und sind über verschiedene Zugriffsmethoden erreichbar.

Das HSM selbst wird bei Manipulation oder unbefugter Bewegung gelöscht. Dies bedeutet, dass sämtliche Schlüsseldaten vom Gerät entfernt werden und autorisierte Benutzer diese Schlüssel von einem Backup-HSM oder von Backups der Schlüsselkomponenten wiederherstellen müssen. Dieser Manipulationsschutzmechanismus macht den physischen Diebstahl von Schlüsseln aus einem HSM praktisch unmöglich.

Die Zahlungsschlüsselhierarchie

Die Zahlungsschlüsselhierarchie definiert die strukturierte Beziehung kryptografischer Schlüssel, die jede Phase einer Zahlungstransaktion schützen. Das Verständnis dieser Hierarchie ist unerlässlich, da jede Ebene festlegt, welche Schlüssel welche Daten entschlüsseln können und zu welchen Operationen diese Schlüssel berechtigt sind.

SchlüsselartAbkürzungStandortZweck
Lokaler HauptschlüsselLMKNur innerhalb des HSM; niemals als Klartext exportiertSchlüsselverschlüsselungsschlüssel für alle anderen Schlüssel im HSM; wird bei der Schlüsselzeremonie festgelegt
Zonen-HauptschlüsselZMKAustausch zwischen Zahlungsstellen; im Ruhezustand mit LMK verschlüsselt.Ermöglicht den sicheren Austausch von Arbeitsschlüsseln zwischen Acquirer-Banken, Zahlungsabwicklern und Kartennetzwerken.
Zonen-PIN-SchlüsselZPKWährend des Austauschs mit ZMK verschlüsselt; im HSM mit LMK entschlüsselt.Verschlüsselt PIN-Blöcke während der PIN-Übersetzung zwischen Zahlungsknoten.
KartenprüfschlüsselCVKVerschlüsselt unter LMK gespeichertGeneriert und überprüft Kartenprüfnummern (CVV/CVC) während der Transaktionsautorisierung.
Terminal-HauptschlüsselTMKIn ein Geldautomaten- oder POS-Terminal geladen; während der Eingabe mit LMK verschlüsselt.Wird auf Terminalebene zur PIN-Verschlüsselung verwendet; wird regelmäßig oder im Falle einer Kompromittierung ausgetauscht.
Nachrichtenauthentifizierungscode-SchlüsselMakVerschlüsselt unter LMKGeneriert und überprüft MACs für Transaktionsnachrichten, um Manipulationen während der Übertragung zu erkennen.

TR-31- und TR-34-Schlüsselaustausch-Workflows

TR-31: Interoperabler sicherer Schlüsselblock

TR-31, veröffentlicht von ASC X9, definiert ein Format zum Einbetten eines symmetrischen Schlüssels zusammen mit seinen Nutzungsattributen in einen kryptografisch gebundenen Schlüsselblock. Der Schlüsselblock enthält Schlüsseltyp, Algorithmus, Nutzungsbeschränkungen und den Schlüsselwert. Alle diese Elemente sind gemeinsam geschützt, sodass die Attribute nicht vom Schlüsselmaterial getrennt werden können. Dies verhindert Schlüsselmissbrauch: Ein ZPK, der ausschließlich zur PIN-Übersetzung verwendet werden soll, kann nicht extrahiert und für eine MAC-Operation verwendet werden, da seine Nutzungsattribute kryptografisch gebunden sind.

Die PCI-PIN-Sicherheitsanforderungen schreiben TR-31 für den gesamten symmetrischen Schlüsselaustausch zwischen Zahlungsinstituten vor. Organisationen, die ZMKs oder Arbeitsschlüssel zwischen Acquirer-Banken, Zahlungsabwicklern oder Kartennetzwerken mit veralteten Clear-Key-Verfahren oder Verfahren vor TR-31 übertragen, erfüllen die aktuellen PCI-PIN-Anforderungen nicht. TR-31-Schlüsselblöcke müssen im Rahmen von PCI-PIN-Prüfungen validiert werden.

TR-34: Asymmetrische Schlüsselverteilung

TR-34 ist ein ASC X9-Standard für die Verteilung symmetrischer Schlüssel mittels asymmetrischer Kryptografie, typischerweise RSA oder ECDH. Er wird für die initiale Schlüsselvereinbarung verwendet, wenn zwei Parteien noch kein gemeinsames symmetrisches Schlüsselmaterial besitzen. Das Schlüsselverteilungszentrum (KDC) verschlüsselt den zu verteilenden Schlüssel mit dem öffentlichen Schlüssel des Empfängers, und das HSM des Empfängers entschlüsselt ihn mit dem zugehörigen privaten Schlüssel. Der gesamte Vorgang findet innerhalb der HSM-Grenzen auf beiden Seiten statt, sodass der Schlüssel niemals im Klartext außerhalb der Hardware offengelegt wird. TR-34 wird im Rahmen von PCI-PIN-Audits geprüft und ist für die konforme initiale Schlüsselvereinbarung in Erfassungs- und Verarbeitungsumgebungen erforderlich.

PCI-PIN-Sicherheitskontrollen und was Auditoren prüfen

Die PCI-PIN-Sicherheitsanforderungen gelten für alle Organisationen, die PINs im Auftrag eines Zahlungskartennetzwerks verwalten. Sie definieren Kontrollen für Hardware-Sicherheit, Schlüsselverwaltung, Personal und Verfahren. Die folgenden Kontrollen sind direkt mit der HSM-Implementierung für Zahlungen verknüpft:

  • HSM-Zertifizierung: Das HSM muss gemäß den PCI PTS HSM-Standards zertifiziert sein. Der Zertifizierungsstatus und die Version müssen dokumentiert und überprüfbar sein.
  • Doppelsteuerung und Split-Kenntnisse: Alle Schlüsselerzeugungs-, Lade- und Austauschvorgänge müssen dem Prinzip der Vier-Augen-Kontrolle (zwei oder mehr autorisierte Personen erforderlich) und der Aufteilung des Wissens (keine einzelne Person hat Zugriff auf den vollständigen Schlüssel) genügen.
  • TR-31-Schlüsselblöcke: Alle symmetrischen Schlüsselaustauschverfahren müssen TR-31-konforme Schlüsselblöcke verwenden. Herkömmliche Methoden zur Verteilung von Klartextschlüsseln sind nicht konform.
  • Tastatureingabe- und Nutzungsbeschränkungen: Jeder Schlüssel im HSM muss eingegeben und auf seine definierte Funktion beschränkt sein. Die Verwendung von Allzweckschlüsseln ist in einem Zahlungs-HSM nicht zulässig.
  • Schlüsselverwahrung und Inventar: Es muss ein aktuelles Verzeichnis aller Schlüssel, Schlüsselverwalter, Schlüsselprüfwerte und Schlüsselverwendung geführt und zur Überprüfung im Rahmen der Beurteilung verfügbar sein.
  • Physische Sicherheit: HSMs müssen in einer physisch sicheren Umgebung mit Zugangskontrollen, Besucherprotokollierung und Umgebungsüberwachung untergebracht werden.
  • Wichtigste Kompromissantwort: Es muss ein dokumentiertes Verfahren zum Umgang mit Schlüsselkompromittierungen existieren und getestet werden, das festlegt, wie kompromittierte Schlüssel identifiziert, widerrufen und ersetzt werden.

Zahlungs-HSM-Schlüsselzeremonie: Verfahren und Dokumentation

Eine HSM-Schlüsselzeremonie für Zahlungen ist ein kontrolliertes Verfahren zur Generierung und zum Laden des lokalen Hauptschlüssels (LMK) oder der Zonen-Hauptschlüssel (ZMKs) unter Vier-Augen-Prinzip und geteiltem Wissen. Die folgenden Schritte beschreiben eine typische LMK-Generierungszeremonie:

  1. Vorbereitungen vor der Zeremonie: Identifizieren Sie die Hauptverantwortlichen (mindestens zwei, typischerweise drei bei einer M-of-N-Aufteilung); holen Sie von jedem Verantwortlichen eine schriftliche Genehmigung ein; bereiten Sie das Zeremonienskript vor; organisieren Sie gegebenenfalls einen Zeugen und einen Prüfer.
  2. HSM-Initialisierung: Wechseln Sie in den administrativen Modus des HSM unter Vier-Augen-Prinzip (beide Verwahrer müssen gleichzeitig anwesend sein); löschen Sie alle vorhandenen Schlüsseldaten; vergewissern Sie sich, dass das HSM-Audit-Protokoll aktiv ist.
  3. Komponentengenerierung: Jeder Schlüsselverwalter generiert seine Schlüsselkomponente innerhalb des HSM oder auf einem dedizierten sicheren Gerät; die Komponente wird auf der Karte oder dem Schlüsselverteilungsgerät des jeweiligen Schlüsselverwalters verschlüsselt; kein Schlüsselverwalter sieht die Komponente eines anderen.
  4. Komponentenkombination: Die Verwalter stellen ihre Komponenten gleichzeitig bereit; das HSM kombiniert die Komponenten, um den LMK innerhalb der Hardwaregrenze zu bilden; außerhalb des HSM ist niemals ein Klartext-LMK zugänglich.
  5. Schlüsselprüfwertprüfung (KCV): Das HSM gibt den KCV für den kombinierten LMK aus; die Verantwortlichen überprüfen, ob der KCV mit dem im Zeremonienskript dokumentierten erwarteten Wert übereinstimmt.
  6. Dokumentation: Jeder Verantwortliche unterzeichnet das Zeremonienprotokoll und bestätigt damit, dass seine Komponente korrekt generiert und geladen wurde; Zeuge und Prüfer unterzeichnen ebenfalls; das Protokoll wird gemäß den Aufbewahrungsvorschriften für PCI PIN-Dokumente aufbewahrt.
  7. Backup-Komponentenspeicherung: Die wichtigsten Komponenten werden in versiegelten, manipulationssicheren Umschlägen an physisch getrennten, sicheren Orten aufbewahrt; der Zugriff auf die Backup-Komponenten erfordert eine Vier-Augen-Kontrolle und wird protokolliert.

Hochverfügbarkeit und Notfallwiederherstellung für Zahlungs-HSMs

Die Zahlungsabwicklung ist eine zeitkritische Infrastruktur. Ausfallzeiten von HSMs führen direkt zu fehlgeschlagenen Transaktionen. Hochverfügbarkeits- (HA) und Disaster-Recovery-Konfigurationen (DR) für Zahlungs-HSMs erfordern eine sorgfältige Planung.

  • LMK-Synchronisierung: Alle HSMs in einem Cluster müssen über einen identischen LMK verfügen. Die LMK-Replikation zwischen den HSMs erfolgt über das sichere Replikationsverfahren des Herstellers und muss unter Vier-Augen-Prinzip mit dokumentierten Nachweisen durchgeführt werden.
  • Lastverteilung: Ein Hardware- oder Software-Loadbalancer verteilt kryptografische Anfragen auf die verfügbaren HSM-Knoten. Anwendungen verbinden sich mit dem Loadbalancer-Endpunkt und wissen nicht, welches physische HSM die jeweilige Anfrage verarbeitet.
  • Geografische Trennung: Primäre und sekundäre HSM-Cluster sollten sich in physisch getrennten Rechenzentren befinden, wobei die Netzwerkverbindungen und die Replikation so ausgelegt sein müssen, dass das im DR-Plan definierte Recovery Time Objective (RTO) eingehalten wird.
  • Kalt-Standby-HSM: Ein Ersatz-HSM, auf dem der gleiche LMK (über die Wiederherstellung der Backup-Komponente) geladen ist, sollte für den schnellen Einsatz verfügbar sein, falls ein primäres HSM außerhalb der Clusterkonfiguration ausfällt.
  • Jährliche DR-Prüfung: Das Verfahren zur Wiederherstellung des HSM-Status aus den Sicherungskomponenten muss dokumentiert und jährlich getestet werden. Die Testergebnisse sind als Prüfungsnachweis aufzubewahren.

Zahlungs- vs. Allzweck-HSMs

Zahlungs-HSMs ( Hardware-Sicherheitsmodule) sind im Gegensatz zu Allzweck-HSMs in vielen verschiedenen Zahlungsorganisationen erforderlich. Insbesondere Banken müssen diese Hardware-Sicherheitsmodule einsetzen, da sie in jedem Land strengen Richtlinien und Vorschriften unterliegen.

AttributZahlungs-HSMAllzweck-HSM
ZertifizierungsanforderungenPCI PTS HSM + FIPS 140-2 oder 140-3FIPS 140-2 oder 140-3 (keine PCI PTS HSM-Zertifizierung)
TastatureingabeJede Taste ist an eine bestimmte Zahlungsoperation gebunden; Nutzungsbeschränkungen werden in der Hardware durchgesetzt.Schlüssel sind vielseitig einsetzbar; Nutzungsbeschränkungen werden durch die Anwendungsrichtlinie durchgesetzt.
Operationen aufgedecktHochrangige Zahlungsvorgänge: PIN-Übersetzung, CVV/CVC, TR-31-Schlüsselblockierung, SchlüsseleinspeisungGrundlegende Operationen: verschlüsseln, entschlüsseln, signieren, verifizieren, ableiten
Durchsetzung der DoppelkontrolleHardwareseitig erzwungene Schlüsselerzeugung und -ladungRichtliniengesteuert; abhängig von der Anwendung und dem Workflow-Design
PIN-Block-VerarbeitungNative Unterstützung für ISO 9564 PIN-BlockformateErfordert benutzerdefinierten Anwendungscode zur Verarbeitung von PIN-Blockformaten
Regulatorische EignungErforderlich für die PCI-PIN-Konformität; erfüllt die HSM-Anforderungen von ZahlungsnetzwerkenGeeignet für PKI, Codesignierung, TLS und allgemeine Verschlüsselung; nicht ausreichend für PCI-PIN-Verwaltungsfunktionen

Anpassbare HSM-Lösungen

Holen Sie sich hochsichere HSM-Lösungen und -Dienste zum Schutz Ihrer kryptografischen Schlüssel.

Integrationsschritte: Bereitstellung eines Zahlungs-HSM

  1. HSM-Zertifizierung bestätigen: Prüfen Sie, ob das HSM über eine gültige PCI-PTS-HSM-Zulassung und ein FIPS-140-2- oder 140-3-Validierungszertifikat verfügt. Stellen Sie sicher, dass die Firmware-Version in der Produktion mit der validierten Konfiguration übereinstimmt.
  2. Entwerfen Sie die Schlüsselhierarchie: Definieren Sie, welche Schlüsseltypen für die betreffenden Transaktionsabläufe benötigt werden (ZMK, ZPK, CVK, TMK, MAK); dokumentieren Sie die Schlüsseltypen, Algorithmen und Nutzungsbeschränkungen, bevor Sie Schlüssel generieren.
  3. Führen Sie die LMK-Schlüsselzeremonie durch: Generieren und laden Sie das LMK unter dualer Kontrolle und geteiltem Wissen gemäß dem oben beschriebenen Zeremonienverfahren; dokumentieren und bewahren Sie alle Zeremonienaufzeichnungen auf.
  4. TR-31 und TR-34 konfigurieren: TR-31-Schlüsselblockunterstützung für den gesamten symmetrischen Schlüsselaustausch mit Gegenparteien implementieren; TR-34 für die erstmalige Schlüsseleinrichtung mit Schlüsselverteilungszentren konfigurieren; End-to-End-Schlüsselaustausch testen, bevor die Verbindung zum Produktionsdatenverkehr hergestellt wird.
  5. Integrieren Sie die Anwendung: Verbinden Sie die Server der Zahlungsanwendung mit der HSM-API (typischerweise PKCS#11 oder eine herstellerspezifische Host-API); konfigurieren Sie die Anwendung so, dass PIN-Übersetzung, CVV-Operationen und Schlüsselaustausch über das HSM geleitet werden; testen Sie alle Transaktionsabläufe in einer Staging-Umgebung.
  6. HA und DR konfigurieren: LMK unter dualer Kontrolle auf den sekundären HSM-Cluster replizieren; Lastverteilung konfigurieren; DR-Verfahren dokumentieren und testen.
  7. Dokumentenprüfungsnachweise: Erstellung und Aufbewahrung von Schlüsselzeremonieprotokollen, HSM-Konfigurationsaufzeichnungen, TR-31-Implementierungsaufzeichnungen, Protokollen der Zwei-Faktor-Authentifizierung und Aufzeichnungen zur physischen Sicherheit für die PCI PIN- und PCI DSS-Bewertungsbereitschaft.

Andere Methoden zum Schutz von Zahlungssystemen

Hardware-Sicherheitsmodule sind nicht die einzige Möglichkeit, Zahlungssysteme zu schützen. Für einen umfassenden Schutz von Zahlungsdaten sind mehrere sich ergänzende Kontrollmechanismen erforderlich:

  • Tokenisierung

    Bei der Tokenisierung werden sensible Zahlungsdaten durch ein nicht-sensibles Token ersetzt, das keine mathematische Beziehung zum ursprünglichen Wert aufweist. Bei der Tokenisierung ohne Datenspeicher ist der Prozess ohne das Tokenisierungssystem unumkehrbar; bei der Tokenisierung mit Datenspeicher kann der ursprüngliche Wert über den Datenspeicher wiederhergestellt werden. Die Zahlungsbranche nutzt die Tokenisierung für gespeicherte Kartendaten und wiederkehrende Zahlungen, da ein Token nicht für betrügerische Transaktionen bei Händlern missbraucht werden kann, die keinen Zugriff auf den Detokenisierungsdienst haben. Siehe auch: Was ist Tokenisierung?

  • Hashing

    Hashing erzeugt einen Hashwert fester Länge aus den Eingabedaten, der nicht umkehrbar ist. Es dient der Überprüfung der Datenintegrität und der Speicherung von Passwortprüfern. Alleiniges Hashing ist für den Schutz von Zahlungsdaten nicht ausreichend, da es keine Vertraulichkeit, sondern lediglich die Integrität gewährleistet.

  • Physische Sicherheit

    Server und Computer, die Kundenzahlungsdaten speichern, müssen in physisch gesicherten Umgebungen mit Zugangskontrollen, Besucherprotokollierung, Umgebungsüberwachung und manipulationssicheren Siegeln an kritischer Hardware untergebracht sein. Die physischen Sicherheitsanforderungen für Zahlungs-HSMs werden im Rahmen von PCI-PIN- und PCI-DSS-Prüfungen bewertet.

Fazit

Der Schutz von Daten an jedem Punkt, insbesondere im Zahlungsverkehr, ist für die Sicherheit von Kundendaten unerlässlich. Payment-HSMs sind die zertifizierte Hardware-Steuerung im Zentrum der PCI-PIN-Konformität. Sie bieten die von den Zahlungsvorschriften geforderte manipulationssichere Umgebung, Schlüsseleingabe, Vier-Augen-Prinzip und TR-31/TR-34-Schlüsselaustauschfunktion. Für Unternehmen, die den Einsatz von Payment-HSMs, gehostete Optionen oder Beratungsleistungen für PCI-PIN-Bewertungen evaluieren, bietet Encryption Consulting HSM-as-a-Service und Verschlüsselungsberatung an . Diese decken HSM-Design, Schlüsselaustausch und die Vorbereitung auf die PCI-PIN-Konformität ab. Die Rolle von Payment-HSMs bei der Verhinderung von Datenschutzverletzungen wird im Artikel „ Die Rolle von Payment-Hardware-Sicherheitsmodulen bei der Verhinderung von Datenschutzverletzungen“ erläutert . Informationen zu PKI-Implementierungen, die Payment-HSM-Implementierungen ergänzen, finden Sie unter „PKI-as-a-Service“.

Häufig gestellte Fragen

Was ist ein Payment-HSM und wie unterscheidet es sich von einem allgemeinen HSM?

Ein Payment-HSM ist ein manipulationssicheres Gerät, das nach PCI PTS HSM und FIPS 140-2 oder 140-3 zertifiziert ist und komplexe Zahlungsvorgänge wie PIN-Blockverschlüsselung, PIN-Übersetzung, Kartenprüfwertgenerierung und TR-31/TR-34-Schlüsselaustausch ausführt. Im Gegensatz zu einem Allzweck-HSM, das kryptografische Basisfunktionen bereitstellt, bündelt ein Payment-HSM diese Funktionen in Zahlungsvorgängen, die vollständig innerhalb der Hardware ausgeführt werden. Die Schlüssel werden dabei typisiert und spezifischen Operationen zugeordnet.

Was ist die Hierarchie der Zahlungsschlüssel und warum ist sie wichtig?

Die Hierarchie der Zahlungsschlüssel beschreibt die strukturierte Beziehung kryptografischer Schlüssel zum Schutz von Zahlungstransaktionen: An oberster Stelle steht der lokale Hauptschlüssel (LMK), gefolgt von den Zonen-Hauptschlüsseln (ZMKs) für den Schlüsselaustausch zwischen den Zahlungsempfängern und den Arbeitsschlüsseln (ZPK für die PIN-Übersetzung, CVK für die Kartenverifizierung, TMK für die Terminal-Injektion, MAK für die Nachrichtenauthentifizierung) auf der operativen Ebene. Jede Ebene ist unter der darüberliegenden Ebene verschlüsselt, wodurch die Angriffsfläche für jeden Kompromittierungsfall definiert wird.

Was sind TR-31 und TR-34 und wann werden sie benötigt?

TR-31 ist ein ASC-X9-Standard, der einen symmetrischen Schlüssel mit seinen Nutzungsattributen in einem kryptografisch gebundenen Schlüsselblock kapselt und so Schlüsselmissbrauch verhindert, indem die Nutzungsattribute untrennbar mit dem Schlüsselmaterial verbunden werden. TR-34 ist ein ASC-X9-Standard für die Verteilung symmetrischer Schlüssel mittels asymmetrischer Kryptografie, wenn kein vorheriger gemeinsamer Schlüssel existiert. Die PCI-PIN-Sicherheitsanforderungen schreiben TR-31 für den gesamten Austausch symmetrischer Schlüssel und TR-34 für die initiale Schlüsselerzeugung vor.

Was beinhaltet eine HSM-Schlüsselzeremonie für Zahlungen?

Die Schlüsselzeremonie im Zahlungs-HSM ist ein kontrolliertes, dokumentiertes Verfahren zur Generierung und zum Laden des lokalen Hauptschlüssels (LMK) unter Vier-Augen-Prinzip und geteiltem Wissen. Mehrere Verwahrer generieren jeweils eine Schlüsselkomponente. Das HSM kombiniert die Komponenten innerhalb seiner Grenzen, sodass kein einzelner Verwahrer jemals den vollständigen Schlüssel besitzt. Die Verwahrer überprüfen den Prüfwert des Schlüssels anhand der erwarteten Referenz. Die Zeremonie wird mit den Unterschriften der Verwahrer dokumentiert und für die PCI-PIN-Prüfung aufbewahrt.

Welche Prüfnachweise muss eine HSM-Implementierung im Zahlungsverkehr erbringen?

Zu den erforderlichen Prüfungsnachweisen gehören: Skripte und Abschlussnachweise der Schlüsselübergabe mit Unterschriften der Schlüsselverantwortlichen; HSM-Zertifizierungsnachweise (PCI PTS HSM und FIPS 140-2 oder 140-3); TR-31-Implementierungsnachweise; TR-34-Schlüsselaustauschnachweise; Dokumentation und Schulungsnachweise zur Vier-Augen-Prinzipie und zur Richtlinie für geteiltes Wissen; Schlüsselinventardaten; HSM-Audit-Log-Exporte; und physische Sicherheitsnachweise.

Wie sollten Zahlungs-HSMs für Hochverfügbarkeit und Notfallwiederherstellung konfiguriert werden?

Zahlungs-HSMs sollten in einer Clusterkonfiguration auf physisch getrennten Racks oder Rechenzentren mit identischem LMK auf allen Knoten bereitgestellt werden. Der Schlüssel wird entweder über dieselbe Schlüsselzeremonie geladen oder gemäß den Herstellervorgaben sicher repliziert. Anwendungen verbinden sich über einen Load Balancer, der Anfragen an verfügbare HSM-Knoten weiterleitet. Ein Cold-Standby-HSM und ein dokumentiertes, jährlich getestetes DR-Verfahren vervollständigen die Hochverfügbarkeits- und Disaster-Recovery-Sicherheit.