Frage:
Was ist die DUKPT-Schlüsselableitungsfunktion?
Hyangelo
2012-03-31 00:47:59 UTC
view on stackexchange narkive permalink

Ich habe die Aufgabe, den von einem verschlüsselten Kartenleser erfassten Chiffretext zu entschlüsseln. Der Kartenleser verwendet das DUKPT-Schema (abgeleiteter eindeutiger Schlüssel pro Transaktion) und die 3DES-Verschlüsselung. Ich habe kein Problem mit der 3DES-Verschlüsselung, da es sich um einen gängigen Algorithmus handelt, der von bekannten Bibliotheken wie BouncyCastle und Java JCE implementiert wird.

Vor dieser Zuweisung hatte ich überhaupt keine Begegnungen mit DUKPT Ich bin ein absoluter Neuling in diesem Bereich.

Nach dem, was ich bisher gelesen habe, verwendet DUKPT einen Schlüsselableitungsmechanismus, der auf einem Basisableitungsschlüssel (BDK) basiert, der im Grunde ein gemeinsamer geheimer Schlüssel und Schlüsselseriennummern für die jeweilige Transaktion ist. Im Fall des Kartenlesers ist jedes Mal, wenn ich wische (auch mit derselben Karte), der Chiffretext anders und der KSN anders. Wie kann ich den Schlüssel für die Transaktion basierend auf diesen Informationen ableiten, wenn ich den BDK, den KSN, den Verschlüsselungsalgorithmus (in diesem Fall 3DES) und den Chiffretext kenne? Ich würde mir vorstellen, dass es eine Art Schlüsselableitungsfunktion gibt, oder?

Drei antworten:
Mark Burnett
2012-03-31 08:54:07 UTC
view on stackexchange narkive permalink

Im Grunde funktioniert es so: Der Server verfügt über einen Hauptschlüssel (BDK) und jedes Clientgerät verfügt über eine eindeutige Seriennummer und einen Zähler (in Kombination die KSN).

Um ein neues Gerät einzurichten, verschlüsseln Sie den KSN mit dem Hauptschlüssel (dem BDK, dem im Link in Yoavs Antwort beschriebenen Vorgang) und erhalten einen neuen Schlüssel (den IPEK). Es ist so, als ob Sie zwei Personen (den Server und den Client) mit zwei Schlüsseln (BDK und KSN) benötigen, um einen Tresor zu öffnen, der einen anderen Schlüssel enthält. Dieser andere Schlüssel ist das IPEK und wird auf dem Gerät selbst installiert.

Das Clientgerät verwendet das IPEK, um eine Tabelle mit zukünftigen Schlüsseln zu erstellen, und verwirft dann das IPEK. Das Client-Gerät hat jetzt seine ursprüngliche Seriennummer, einen Zähler (kombiniert sind die KSN) und eine Liste der zukünftigen Schlüssel.

Um die Daten zu verschlüsseln, nimmt das Clientgerät den ersten Future Key aus der Liste und verwendet diesen als Verschlüsselungsschlüssel. Anschließend werden die verschlüsselten Daten und der KSN (der den Zähler enthält) an den Server gesendet.

Auf der Serverseite kennt der Server sein eigenes Geheimnis (das BDK) und verfügt nun über die KSN des Clent-Geräts. Der Server verwendet diese beiden Schlüssel, um das IPEK zu erstellen (öffnen Sie den Tresor erneut). Mit dem IPEK kann der Server die Tabelle der zukünftigen Schlüssel neu erstellen und kennt den vom Client bereitgestellten Zähler (die letzten 5 Zeichen des KSN). Er weiß, welcher Schlüssel aus der Tabelle verwendet werden soll.

Was alle technischen Details betrifft, würde ich vorschlagen, sich in Andy Orrocks Blog (verlinkt in Yoavs Antwort) umzuschauen und vielleicht eine Kopie von ANSI X9.24 zu erhalten, die die vollständige Spezifikation enthält.

"Mit dem IPEK kann der Server die Tabelle der zukünftigen Schlüssel neu erstellen und den vom Client bereitgestellten Zähler (die letzten 5 Zeichen des KSN) kennen. Er weiß, welcher Schlüssel aus der Tabelle verwendet werden soll." Dies ist der Teil, den ich noch wissen muss. Wie erstelle ich den Schlüssel basierend auf dem Zähler neu?
Yoav Aner
2012-03-31 02:01:44 UTC
view on stackexchange narkive permalink

Es konnten nicht viele Ressourcen online gefunden werden, aber ich kann mir vorstellen, dass dies irgendwo ziemlich umfassend spezifiziert werden sollte. Was ich jedoch herausgefunden habe, ist diese Beschreibung des Ableitungsprozesses.

Wenn ich das richtig verstehe, funktioniert die Ableitungsfunktion ungefähr wie folgt:

  1. Der KSN wird normalisiert unter Verwendung einer Art Auffüllung
  2. Der normalisierte KSN wird dann verschlüsselt mit dem BDK
  3. Die Ausgabe dieses Prozesses ist der abgeleitete Schlüssel für die Transaktion
  4. ol>

    Hope Ich führe dich nicht in die Irre. Dies verdient wahrscheinlich eine Antwort von jemandem, der mit den tatsächlichen Spezifikationen besser vertraut ist.

RC Bryan
2012-04-19 10:30:46 UTC
view on stackexchange narkive permalink

Die Details zum Erstellen der zukünftigen Schlüssel sind ziemlich schrecklich, aber sie sind in der ANSI-Spezifikation enthalten. Die Spezifikation ist nicht offiziell online verfügbar. Wenn Sie jedoch in Google nach "Baidu ansi x9.24" suchen, erhalten Sie einen Link zur Version 2004 (die aktuelle Version ist 2009). Das Lesen auf der Baidu-Website (die chinesische Antwort auf Google) ist unangenehm, aber die 140 US-Dollar, die ANSI verlangen möchte, sind noch unangenehmer. Nachdem ich das Geld in die aktuelle Version der Spezifikation investiert habe (nachdem ich einige Tage mit Baidu gespielt habe), kann ich bestätigen, dass der Prozess alles andere als offensichtlich ist.

Ich denke, ich sollte kommentieren, dass ich die Beispiele aus der Spezifikation erhalten habe, die mit den OpenSSL 3DES-Routinen arbeiten.
Du hast recht, ich habe einen kurzen Blick darauf geworfen und es sieht entmutigend aus. In dem Anhang, in dem der Algorithmus beschrieben wurde, sind Stil und Ton des Dokuments nicht freundlich. Zu Ihrer Information, wir haben uns für den Magensa-Service von MagTek entschieden, der die Workloads für die Schlüsselverwaltung und -entschlüsselung von unserem Rücken entlastet.
Es klingt so, als würde das eine Menge Kopfschmerzen ersparen. Ich wünschte, wir hätten das als Option.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...