トランザクションごとの派生一意キー（DUKPT）のキーシリアル番号（KSN）について
[〜＃〜] dukpt [〜＃〜] にキーシリアル番号（KSN）に関するいくつかの質問があります。
- KSNの長さは8〜10バイトです。古い実装は8バイトですが、新しい実装は10バイトです。 10バイト長のKSNを作成すると、古いシステムとの互換性がなくなるリスクはありますか？
- KSNには3つのコンポーネントがあります。21ビットのトランザクションカウンターと残りのビットは、キーセットIDと改ざん防止セキュリティモジュール（TRSM）ID用です。 8バイトのKSNの一般的な規則は、キーセットIDの場合は24ビット、TRSM IDの場合は19ビットです。これは、約16Mの基本導出キー（BDK）と500Kデバイスを意味します。私にとって、この割り当てには長所と短所があります。短所は、16MのBDKが決してないことであり、ビジネスが成功すれば、500,000を超えるデバイスを使用できる可能性があります。利点は、500Kを超えるデバイスで同じBDKを使用しないことを強制することで、1つのBDKの危険性が制限されます。私は、キーセットIDとTRSM IDに割り当てられるビット数に柔軟性があることを読みます。そのため、最大50万のBDKと16Mのデバイスを使用できるように、割り当てを入れ替えたくなります。しかし、24〜19〜21ビットの分割を想定したDUKPTのオープンソース実装も数多く見かけます。規約に従わないと、これらの実装はすべて失敗します。私は慣習に固執することをお勧めしますか？
- キーセットIDを設定する標準的な方法はありますか、またはBDKを所有するすべてのエンティティが独自の規則を考え出しますか？最初のBDKにキーセットID = 1を割り当て、新しいBDKごとに1ずつ増分できますか？それとも、その戦略は単純すぎるのでしょうか？
- TRSM IDを設定する標準的な方法はありますか？新しいBDKを使用して注入された最初のデバイスにTRSM ID = 1を割り当て、新しいBDKごとに1ずつ増やすことはできますか？
8/10バイト。標準では常にKSNが10バイト（80ビット）でしたが、左側に0xFFを埋め込んだ小さな値が許可されており、多くの人が8バイトを使用または使用していました。どちらにしても明確なパターンがあるとは言えません。処理するデバイス（またはシステム）が8バイトに制限されている場合は、8バイトを使用します。以下のように、とにかく今は基本的に任意です。
あなたは正しいですほぼ全員がxx-19-21ビットを使用しているようです-= 8バイトでは24-19-21ビットです。 DUKPTはもともと数千ドルの費用がかかるATM用に設計されたことを思い出してください。したがって、512Kは厄介な制限ではありませんでした。現在、人々はそれをマッチボックスに使用しています。技術的にはカウンターパート（xx-21）のみが暗号化に関係するため、プログラム、API、パートナーなどがそれを処理できる場合は、他の境界をシフトできます。慣習に固執する場合、OTOHの方が簡単です。異なるKSIが常に異なるBDKにマップする必要があるということは何もありません。あなたが持つことができます
[FFFF]ABAB00-mmmmmはBDKの最初の512Kデバイスです[〜＃〜] a [〜＃〜]、ABAB01-mmmmmは秒512Kなど、ABAB50は、BDKの最初のバッチです[〜＃〜] b [〜＃〜]など。数十または数百のバッチ（5,000以上のデバイス）だけを管理する必要がある限り、これは結構です。 5億を超える数が必要な場合は心配しますが、それまでにこれを変更するのに十分な影響力があります。当初の考えは[〜＃〜] ksi [〜＃〜]は銀行または銀行のサブパート（ATM、覚えている）を識別し、グローバルに一意であるため、決済ネットワーク内の暗号文はすべて自己-「所属する」人物を特定/確認します。今日、KSIは基本的に恣意的になっているので、はい、好きなものを選択してくださいです。ただし、先頭にゼロがある値は使用しないことをお勧めします。あまりにも多くのものは、数値に見える（16進数に見える）値の先行ゼロは重要ではないと考え、それらを落とす傾向があります。
TRSM ID（またはデバイスID）：はい、単に連番を使用します。ただし、
-00000-tttttおよび-00001-tttttはデバイス0、-00002-tttttプラスはデバイス1、...-FFFFE-tttttプラスはデバイス0x7FFFFです。