為に
`BDK = "0123456789ABCDEFFEDCBA9876543210"` `KSN = "FFFF9876543210E00008"`
生成された暗号文は以下でした
"C25C1D1197D31CAA87285D59A892047426D9182EC11353C051ADD6D0F072A6CB3436560B3071FC1FD11D9F7E74886742D9BEE0CFD1EA1064C213BB55278B2F12"`
ここで見つけました。この暗号文が BDK と KSN に基づいていることは知っていますが、この 128 の長さの暗号文はどのように生成されたのでしょうか? それに含まれるステップまたはこれに使用されるアルゴリズムは何ですか? 誰かが簡単な手順で説明できますか。グーグル検索中に入手したドキュメントを理解するのに苦労しました。
DUKPTについては、 Wikiにいくつかの説明があります。これで十分でない場合は、簡単な説明を次に示します。
http://www.maravis.com/library/derived-unique-key-per-transaction-dukpt/を引用
DUKPTとは？
Derived Unique Key Per Transaction (DUKPT) はキー管理スキームです。暗号化するエンティティ (またはデバイス) とデータを復号化するエンティティ (またはデバイス) によって共有されるシークレット マスター キーから派生したワンタイム暗号化キーを使用します。なぜDUKPT? 暗号化アルゴリズムは、その鍵と同じくらい安全です。アルゴリズムでデータを暗号化するために使用されるキーが安全でない場合、最も強力なアルゴリズムは役に立ちません。これは、最大かつ最強のロックでドアをロックするようなものですが、ドアマットの下にキーを隠した場合、ロック自体が役に立たなくなります. 暗号化について話すときは、相手側でデータを復号化する必要があることにも留意する必要があります。通常、どの暗号化方式でも最も弱い部分は、暗号化側と復号化側の間で鍵を共有することです。DUKPT は、両当事者が暗号化/復号化キーを渡すことなくデータを暗号化および復号化できるようにするための試みです。VISA が発行した暗号化のベスト プラクティス ドキュメントでも、PCI DSS 準拠のために DUKPT の使用が推奨されています。
DUKPT の仕組み
DUKPT は、トランザクションごとに生成されてから破棄される 1 回限りのキーを使用します。利点は、これらのキーの 1 つが危険にさらされた場合、1 つのトランザクションのみが危険にさらされることです。DUKPT では、発信側 (ピン入力デバイスまたは PED など) と受信側 (プロセッサ、ゲートウェイなど) がキーを共有します。この鍵は、実際には暗号化には使用されません。代わりに、このマスター キーから派生した別のワンタイム キーを使用して、データの暗号化と暗号化解除を行います。マスター キーは、派生したワンタイム キーから回復できないことに注意することが重要です。データを復号化するには、受信側は、ワンタイム キーの生成に使用されたマスター キーを認識している必要があります。これは、受信側が各デバイスのマスター キーを保存して追跡する必要があることを意味します。これは、多くのデバイスをサポートする人にとっては大変な作業です。これに対処するには、より良い方法が必要です。実際の動作は次のとおりです。受信者には、Base Derivation Key (BDK) と呼ばれるマスター キーがあります。BDK は秘密であると想定されており、誰とも共有されることはありません。このキーは、初期ピン暗号化キー (IPEK) と呼ばれるキーを生成するために使用されます。これから、Future Keys と呼ばれるキーのセットが生成され、IPEK は破棄されます。Future キーのそれぞれは、デバイス メーカーによって PED に埋め込まれ、共有されます。この追加の派生ステップは、受信者が PED に入るすべてのキーを追跡する必要がないことを意味します。必要に応じて再生成できます。このキーは、初期ピン暗号化キー (IPEK) と呼ばれるキーを生成するために使用されます。これから、Future Keys と呼ばれるキーのセットが生成され、IPEK は破棄されます。Future キーのそれぞれは、デバイス メーカーによって PED に埋め込まれ、共有されます。この追加の派生ステップは、受信者が PED に入るすべてのキーを追跡する必要がないことを意味します。必要に応じて再生成できます。このキーは、初期ピン暗号化キー (IPEK) と呼ばれるキーを生成するために使用されます。これから、Future Keys と呼ばれるキーのセットが生成され、IPEK は破棄されます。Future キーのそれぞれは、デバイス メーカーによって PED に埋め込まれ、共有されます。この追加の派生ステップは、受信者が PED に入るすべてのキーを追跡する必要がないことを意味します。必要に応じて再生成できます。
受信者は、各 PED に 1 つのキーを埋め込む PED メーカーと Future キーを共有します。これらのキーのいずれかが侵害された場合、BDK はまだ安全であるため、BDK から派生した新しい Future キーで PED のキーを再生成できます。
暗号化と復号化
データを PED からレシーバーに送信する必要がある場合、そのデバイス内のフューチャー キーを使用してワンタイム キーを生成し、このキーを暗号化アルゴリズムと共に使用してデータを暗号化します。このデータは、デバイス ID とデバイス トランザクション カウンターで構成されるキー シリアル番号 (KSN) と共に受信者に送信されます。
KSN に基づいて、受信者は IPEK を生成し、そこからデバイスによって使用された将来のキーを生成し、次にデータの暗号化に使用された実際のキーを生成します。このキーを使用して、受信者はデータを復号化できます。
まず、あなたがリンクした完全なソースコードを引用させてください.3行だけを提供しました...
require 'bundler/setup'
require 'test/unit'
require 'dukpt'
class DUKPT::DecrypterTest < Test::Unit::TestCase
def test_decrypt_track_data
bdk = "0123456789ABCDEFFEDCBA9876543210"
ksn = "FFFF9876543210E00008"
ciphertext = "C25C1D1197D31CAA87285D59A892047426D9182EC11353C051ADD6D0F072A6CB3436560B3071FC1FD11D9F7E74886742D9BEE0CFD1EA1064C213BB55278B2F12"
plaintext = "%B5452300551227189^HOGAN/PAUL ^08043210000000725000000?\x00\x00\x00\x00"
decrypter = DUKPT::Decrypter.new(bdk, "cbc")
assert_equal plaintext, decrypter.decrypt(ciphertext, ksn)
end
end
さて、あなたは「暗号文」がどのように作成されたかを尋ねています...
まず最初にわかっているのは、それが「平文」に基づいており、復号化が機能するかどうかを検証するためにコードで使用されているということです。
平文は 0 で埋められます - これは、この DecrypterTest TestCase で復号化を検証することによってテストされている暗号化に適合します。
それではエンコーディングコードを見てみましょう...
関連する暗号化コードはhttps://github.com/Shopify/dukpt/blob/master/lib/dukpt/encryption.rbで見つかりました。
DecrypterTEst は「cbc」を使用するため、暗号化に次のものが使用されることが明らかになります。
@cipher_type_des = "des-cbc"
@cipher_type_tdes = "des-ede-cbc"
その暗号化コードをもう少し掘り下げると、次のように答えを求める私たちの探求が解決されます。
ciphertext = des_encrypt(...
これは、DES 暗号化の結果を見ていることを示しています。
現在、DES のブロック サイズは 64 ビットです。それは（64/8 =）8バイトのバイナリ、または- 「暗号文」はバイトの16進数でエンコードされたテキスト表現であるため-16文字の16進数です。
「暗号文」の長さは 128 の 16 進文字です。つまり、暗号化された情報の各 64 ビットを含む 8 つの DES ブロック (128 の 16 進文字/16 の 16 進文字 =) を保持します。
これらすべてを簡単な答えにまとめます。
"ciphertext"を見ると、(8 ブロックの) DES 暗号化データが表示されます。これは、DES 暗号化が元のバイナリ バイトになる代わりに、人間が読める 16 進数 (2 16 進文字 = 1 バイト) 表記を使用して表されます。生産。
暗号文の「再作成」に含まれる手順については、質問の基になったルビープロジェクトの関連部分を使用するように言う傾向があります。ソースコードを見るだけです。「https://github.com/Shopify/dukpt/blob/master/lib/dukpt/encryption.rb」のファイルは、ほとんどすべてを説明しており、必要なすべての機能はプロジェクトの GitHub で見つけることができると確信しています。リポジトリ。または、好みのプログラミング言語を使用して、自分で再作成することもできます。処理する必要があるのは、DES 暗号化/復号化と、ビンから 16 進数/16 進数からビンへの変換の 2 つだけです。
これを見てください: https://github.com/sgbj/Dukpt.NET、同様の状況にあり、端末に INIT と KSN を使用して作成する独自の関数呼び出しがある場合、端末に dukpt を実装する方法を考えていました。最初のキーなので、私の唯一の問題は、INITキーが上記のレポのコードと同じ方法でターミナル上で生成されたことを確認することでした。 .