HSMへのハッシュおよび対称暗号化のオフロード
（PKCS＃11）ベースのHSM（S/MimeまたはPGP用）を使用する場合、署名または復号化のための公開鍵操作はHSMによって行われるため、鍵は保護された環境から出てはなりません。これらの操作の大部分（署名の場合はダイジェストの作成、暗号化の場合は対称暗号）はホストが実行できます。
ただし、ほとんどのPKCS＃11実装（低速のスマートカードでも）は対称暗号とハッシュさえ提供していることに気付きました。その理由がわかります。
- 暗号化インターフェースとハードウェア実装を使用することで、（強化された）FIPSコンプライアンスと主張できます
- 攻撃者ベースの生のダイジェストの代わりにすべてのバイをコンポーネントに送信することにより、既知の暗号文（RSAの場合）による攻撃を削減します。
- hSMに、公開されることのないセッションキーを生成または導出させる（これが実際にサポートされている場合）。
- キー生成にハードウェア乱数ソースを利用する
しかし、実際には意味のないことがいくつかあるので、ベストプラクティスは何ですか（ほとんどの場合、提供する必要がある構成可能性を定義するため）。
- PKCS＃11で「ランダムセッションキーをRSAで暗号化してAESに使用する」操作を見たことがないので、この期待される保護は存在しません。それとも何か不足していますか？
- ハッシュの署名はオフロードできると思いますが、ほとんどのHSMでは「生のダイジェスト」攻撃を閉じることができず、署名キーを安全なRSA（パディング）操作に制限する方法がないようです。
- hSMは、特にバルク操作のハードウェア拡張パフォーマンスを主張しますが、最新の汎用CPUに対応できません（特に、データをネットワークインターフェイス経由でHSMへの安全なメッセージングで転送する必要がある場合は、コプロセッサまたはPCIソリューションのみがより高速になります） ）。したがって、速度の利点はめったにありません。
それで、HSMを使用して、2つのプロバイダーを指定したり、ローカルの一括操作にフォールバックするように構成可能にしたりすることは一般的ですか？私はいくつかのツールをチェックし、それらのほとんどはアプリケーション全体または操作（「ハッシュ+記号」のような）のために暗号化エンジンを構成することを可能にします。 「RSAの場合はXを使用し、SHAを使用する場合はyを使用する」と言うことができる構成ファイルを見たことがありません。非ハッシュの場合、ほとんどがデフォルトの（ローカル）ハッシュにフォールバックすると思いますメカニズムが選択されていますか？人々はそれで満足していますか？
PKCS＃11で「ランダムセッションキーをRSAで暗号化してAESに使用する」操作を見たことがないので、この期待される保護は存在しません。それとも何か不足していますか？
いいえ、PKCS＃11にはそのような操作はありません。それを行う場合は、基本的な関数呼び出しから自分で構築する必要があります。対称鍵を生成し（HSMでエントロピーソースを使用）、対称鍵を非対称鍵でラップし、一括暗号化を行います。
ハッシュの署名はオフロードできると思いますが、ほとんどのHSMでは「生のダイジェスト」攻撃を閉じることができず、署名キーを安全なRSA（パディング）操作に制限する方法がないようです。
PKCS＃11デバイスは、入力データの処理方法を指定するmechanismsのリストをサポートしています。最も一般的なものは、歌うためのCKM_RSA_PKCS_PSSおよびCKM_RSA_PKCSと、暗号化のためのCKM_RSA_PKCS_OAEPまたはCKM_RSA_PKCS（および未加工のRSAのためのCKM_RSA_X_509）です。
トークンのメカニズムを完全に無効にする以外に、キーを特定のメカニズムに制限する方法はありません。それが必要な場合は、下位レベルで実行し、PC/SCを介してデバイスに直接アクセスする必要があります（可能な場合）。
hSMは、特にバルク操作のハードウェア拡張パフォーマンスを主張していますが、特に最新の汎用CPUに対応できないため（特に、データをネットワークインターフェイス経由でHSMへの安全なメッセージングで転送する必要がある場合）、速度の利点はありません。
そのための実際の答えはありません。用語[〜＃〜] hsm [〜＃〜]は、2桁から5桁の€番号までの非常に幅広いデバイスを網羅しています。小規模な暗号化トークンまたはスマートカードは、AESを実行するときは最新のCPUよりも明らかに遅くなりますが、そこには明らかに高速なデバイスがあります（「SSLアクセラレータ」カテゴリを確認してください）。