デバイス上の最後のブロックをハッシュすることで何が得られますか？
最近、「最後のブロックをデバイス上でハッシュする」という概念に遭遇しました。
これは、デジタル署名を計算するときに、実際の署名計算の入力として機能するハッシュは、完全にソフトウェアで計算されるのではなく、完全にハードウェアで計算されないことを意味します。実際、ダイジェスト計算の最初のn-1ブロックはソフトウェアで計算されます。パフォーマンス上の理由から、最終的なハッシュが署名の計算に使用される前に、デバイス（通常はスマートカード）で最終的なブロックが計算され、再びデバイス上で実行されます。
私が当時使用していたカードのスマートカードドライバーは、デバイス上で完全に署名を生成するように要求されたときとまったく同じであると言われました（ハッシュ+署名の計算）：ドライバーは最初のn-1ブロックをローカルで計算し、次にダイジェストの現在の状態でスマートカードを初期化し、残りのデータをハッシュのファイナライズと署名の計算に送信します。
これによりセキュリティが強化されると言われ、最初はソフトウェアで計算されたハッシュを傍受し、自分で選択したハッシュに置き換えて、有効な署名を取得する攻撃者に対する巧妙な対策として意図されていました選択したデータ。
しかし、私はそれについて考えれば考えるほど、混乱しました。攻撃者が同じ方法でハッシュを事前に作成することを妨げるものは何もありません。つまり、選択したデータに対してダイジェスト計算のn-1ステップを計算し、これをデバイスに送信してファイナライズします。これも完全に細かい偽造署名を生成します。
ソフトウェアで完全にハッシュを計算するよりもなぜこれが好ましいのかについて私が考えることができる唯一の議論は、法的な性質のものです。デバイスとそのアルゴリズムが認定されている場合、署名の計算用の入力データが認定された実装によって提供されていることが保証されますが、ハッシュが認定されていないデバイスによって完全にデバイスの外部で計算された場合、そのような保証はありません。サードパーティソフトウェア。これが特定の署名についての論争の場合の法的議論に影響を与えると想像することができます。
私が見落としたセキュリティの本当の利点はありますか？
引用元 Wolfgang Rankl、Wolfgang Effingによるスマートカードハンドブック
PERFORM SECURITY OPERATIONコマンドのHASHオプションを使用して、ハッシュ値を計算できます。このコマンドは、ハッシュするデータ、またはスマートカードの外部で既に計算されたハッシュ値を、計算の最終ステップに必要なデータとともに転送できます。後者の場合、最終ブロックのハッシュ計算はカードで実行されます。後者の方法の利点は、カードの外側でハッシュ値を大幅に高速に生成できることですが、最後のステップはカードの内側で発生します。純粋に暗号化の観点から見ると、これはわずかな追加のセキュリティしか提供しませんが、ハッシュ値を操作する可能性を多少制限します。このため、実際に広く使用されています。
通常、ハッシュの最後のブロックにはデータ長（「最終ステップに必要なデータ」）が含まれています。
このブログ は、PERFORM SECURITY OPERATION：HASHコマンドのすべてのモードについて説明しています。それらは：スマートカード上のすべてをハッシュします。データの最後の部分をハッシュする（このpardの長さについては何も言わない）。何もハッシュ化せず、署名するだけです。
この記事 は言う：
パフォーマンス上の理由から、ハッシュ関数は一般にカードの外部で実行されることを指摘しておこう。特に、デジタル署名関数がキー付きMAC関数の場合、最後のブロック計算のみがカードで実行されます。
述べたように、そのポリシーは奇妙です。真のデジタル署名（RSAまたはECDSAなど）の場合、署名されるメッセージは最初にハッシュされ、残りの操作では結果のハッシュ値のみが使用されます。ハッシュ計算はパブリック要素のみを使用します。ハッシュにはキーがありません。したがって、スマートカードでハッシュ計算の一部を実行することを要求することは、スマートカードが取得するメッセージデータに基づいて署名の完成を控える場合、つまりスマートカードがメッセージを拒否できる場合にのみ、セキュリティ面で意味があります。値0x5Fのバイト、またはその他の同様の任意のフィルタリングルールで終わっていません。このようなルールは、デバイスの署名ではかなり珍しいものです。さらに、「スマートカードの最後のブロック」のポリシーとSHA-256などの通常のハッシュ関数を使用すると、スマートカードは最後のメッセージビット（メッセージの長さに応じて0から447ビットの間）とメッセージの全長を取得します。これは、意味のあるフィルタリングルールではそれほど多くありません。このようなありそうもないフィルターがない場合、メッセージの最後のブロックをスマートカードで処理する必要があっても、セキュリティはまったく向上しません。
おそらく、そのようなポリシーは、厳格な法的要件の不正な履行である可能性があります。たとえば、一部の規制では、ハッシュが「スマートカードで発生する」ことを義務付け、最後のブロックのみの処理でコンテンツを感じる場合があります。類推として、EUが自動車の輸入に厳しい割り当てを実施していた時期がありました。日本の建設業者は、ハンドルのない車だけでなく、ハンドルもイギリスの「工場」に送ることを想像しました。そこでは、ほとんど車とハンドルが組み立てられていました。これは、ヨーロッパの規制によると、「ヨーロッパ製」の車を製造するのに十分であり、したがって割り当て量の対象にはなりませんでした。
ただし、スマートカードの「最後のブロックをハッシュする」というポリシーがより理にかなった別のシナリオがあります。 [〜＃〜] hmac [〜＃〜] を使用します。 HMACは メッセージ認証 ;用です。これは「真の」デジタル署名ではありませんが、MACを指定するために「署名」という用語を使用することは広く使用されています（不適切ですが）。
したがって、HMACは次のようになります。秘密鍵から[〜＃〜] k [〜＃〜]は、2つのブロックサイズの値Kから導出されます1およびK2（派生は、単純なXORを従来のシーケンスで使用し、派手なものは何もありません。重要な点は、K1およびK2ハッシュ関数ブロックのサイズ（つまり、ハッシュ関数がSHA-1またはSHA-256の場合は64バイト）。次に、ハッシュ関数hを使用して、メッセージmのMACが次のように計算されます：h（ K1 || h（K2 || m））。
したがって、HMAC計算の大部分は基本的にメッセージのハッシュですm;ただし、キーから派生したブロックのハッシュで開始する必要があり、最後に追加のハッシュ操作（ここでも別のキーから派生したブロック）があります。望まないK1またはK2スマートカードを終了します（そうでなければ、スマートカードを使用することはほとんど意味がありません）。ただし、スマートカードは（CPUまたはI/O帯域幅のいずれにおいても）強力ではないため、外部コンピューター（スマートカードドライバー内）でほとんどの作業を実行することをお勧めします。次に、HMAC計算は次のようになります。
ドライバーは、HMAC計算を実行する必要があることをスマートカードに通知します。スマートカードプロセスK2ハッシュ関数を介して、その時点で達成されたハッシュ関数の状態をドライバーに返します（これはの使用可能な情報をリークしません）[〜＃〜] k [〜＃〜]Kのため2はブロックのサイズです）。このステップはmに依存しないため、ここでは実際の計算は必要ありません。スマートカードがキーを取得（生成）したときに、キーに依存する状態が一度だけ計算された可能性があります[〜＃〜] k [〜＃〜]そもそも。
ドライバは、スマートカードから取得したハッシュ関数の状態から始めて、mをハッシュします。ドライバはそのハッシュ計算を（パディング付きで）完了し、結果の値（h（K2 || m））からスマートカードへ。
次に、スマートカードは2番目のハッシュ（Kを使用するハッシュ）を計算します1）。再び、処理後にハッシュ関数の状態が達成されましたK1は事前に計算されている可能性があるため、真のオンライン作業は単一のハッシュ関数ブロックの処理にあります。
このシナリオでは、スマートカードに秘密キーを保持しながら、ホストコンピューターの速度で、高速で外部化された計算を行うことができます。私の推測では、「スマートカードの最後のブロック」のポリシーがアドバタイズされる場合、それらは本当に、先ほど説明したようにHMAC計算を意味していると思います。これはずさんな用語を必要とします（MACは署名ではありません）が、EUのような官僚的な不条理よりも優れています。