web-dev-qa-db-ja.com

DUKPTキー導出関数とは何ですか?

暗号化されたカードリーダーから取得した暗号文を復号化する必要があります。カードリーダーは、DUKPT(トランザクションごとの派生一意キー)スキームと3DES暗号化を利用します。 3DES暗号化はBouncyCastleやJava JCE。のようなよく知られたライブラリによって実装された一般的なアルゴリズムであるため、問題はありません。

この割り当ての前は、DUKPTとの出会いはまったくなかったので、これはまったくの初心者です。

これまで読んだことから、DUKPTは基本的には特定のトランザクションの共有秘密鍵と鍵シリアル番号であるBase Derivation Key(BDK)に基づく鍵導出メカニズムを利用しています。カードリーダーの場合、スワイプするたびに(同じカードでも)、暗号化テキストは異なり、KSNも異なります。 BDK、KSN、暗号化アルゴリズム(この場合は3DES)、および暗号テキストを知っているので、この情報に基づいてトランザクションのキーを導出するにはどうすればよいですか?ある種の鍵導出関数があると思いますか?

13
Hyangelo

基本的には次のように機能します。サーバーにはマスターキー(BDK)があり、各クライアントデバイスには一意のシリアル番号とカウンターがあります(これらを組み合わせるとKSNになります)。

新しいデバイスをセットアップするには、マスターキー(BDK、Yoavの回答のリンクに記載されているプロセス)を使用してKSNを暗号化し、新しいキー(IPEK)を取得します。これは、別のキーを含むボールトを開くために2つのキー(BDKとKSN)を持つ2人(サーバーとクライアント)が必要になるようなものです。その別のキーはIPEKであり、デバイス自体にインストールするものです。

クライアントデバイスはIPEKを使用してフューチャーキーのテーブルを作成し、IPEKを破棄します。したがって、クライアントデバイスには、元のシリアル番号、カウンター(KSNを組み合わせたもの)、およびFuture Keysのリストがあります。

データを暗号化するために、クライアントデバイスはリストから最初のフューチャーキーを取得し、それを暗号化キーとして使用します。次に、暗号化されたデータとそのKSN(カウンターを含む)をサーバーに送信します。

サーバー側では、サーバーはそれが自分の秘密(BDK)であることを認識しており、現在はクライアントデバイスのKSNを持っています。サーバーはこれら2つのキーを使用してIPEKを生成します(そのボールトを再度開きます)。 IPEKを使用すると、サーバーはFuture Keysのテーブルを再作成でき、クライアントから提供されたカウンター(KSNの最後の5文字)を認識して、テーブルから使用するキーを認識できます。

すべての技術的な詳細については、Andy Orrockのブログ(Yoavの回答にリンクされています)を見て、フルスペックのANSI X9.24のコピーを入手することをお勧めします。

15
Mark Burnett

オンラインで多くのリソースを見つけることができませんでしたが、どこかでかなり包括的に仕様化されているはずです。しかし私が見つけたのは この導出プロセスの説明 です。

これを正しく理解すると、派生関数はおおよそ次のように機能します。

  1. KSNは、何らかの形式のパディングを使用してnormalizedです
  2. 正規化されたKSNは、次にBDKencryptedされます
  3. このプロセスの出力は、トランザクションの派生キーです。

私があなたを誤解させないことを願っています。これはおそらく、実際の仕様に詳しい人からの回答に値するでしょう。

10
Yoav Aner

将来のキーを作成する方法の詳細は非常に恐ろしいですが、それらはANSI仕様に含まれています。仕様は公式にはオンラインで利用できませんが、Googleで「Baidu ansi x9.24」を検索すると、2004バージョン(現在は2009)へのリンクが表示されます。 Baidu(Googleに対する中国の回答)Webサイトでそれを読むのは不愉快ですが、ANSIが請求する140ドルはさらに不愉快です。 (Baiduで数日間遊んだ後)仕様の現在のバージョンにお金を投資したので、プロセスが明白ではないことを証明できます。

5
RC Bryan